Hierarchy for reading Rayleigh constants within custom reference framework

[illorenzo7]

Hi all (in particular @tukss @lkorre @jorafb @feathern; please let me know if there are others who use the custom reference framework whom I may have missed; also does anyone have Brad's Github handle? I can't find it and I think he should be part of this).

This is a follow-up to my other issue (#419) on the custom reference interface/heating_type. From the discussion a year ago, it seemed there were a variety of ways various constants / functions could be set when either reference_type = 4 or [diffusivity]_type = 3 (and hopefully heating_type = 5 soon!) I think it was unclear which ways of specifying the constants took precedence. For example, if in main_input, the user specifies

override_constants(5) = .true.
ra_constants(5) = 2.0d0
nu_top = 3.0d0

What happens?

I'm not actually sure what (if anything) needs updating, but I suspect at least some use cases' behavior are unclear. I am also not sure if all the mechanisms to specify constants are actually in use. I think it would be helpful if everyone whom changing anything would affect could chime in with answers to the following questions:

In main_input, does anyone specify:

1. override_constant, override_constants, ra_constants
2. with_custom_reference, with_custom_constants, with_custom_functions
3. any of the above, or any of the custom types, along with: angular_velocity, luminosity, ekman_number, nu_top, etc. (non-exhaustive list; basically, does anyone specify a custom-anything, along with a keyword in Rayleigh that affects one of the constants?)

From our discussion, I think we tentatively decided on the following hierarchy (my memory is a bit vague, so please chime in if you foresee issues):

"override" trumps "with_custom" trumps "Rayleigh keyword" trumps [whatever the reference state was before these options are implemented]

I also think I might be guilty of forcing @feathern a long time ago to modify things so that I could, e.g. specify nu_top and angular_velocity along with reference_type = 4. If that is the case (sorry Nick!!) I propose simply ignoring the Rayleigh keywords when something is "custom." I think currently it's an issue only for angular_velocity --> c_1 and [luminosity or heating_integral] --> c_10.

Again, I'd like to make this into a pull request after some discussion, so please do comment if you foresee any problems with your use of custom reference, following the implementation of the above hierarchy (or would you suggest a different hierarchy, for example?)

-Loren