Overhaul approach to physical constants and model parameters

[white-alistair]

Currently, there is not a clear distinction between universal physical constants, which never change, and model parameters, which might.

Copying @milankl's comment from PR #82:

What about using "constants" for actual physical constants that nobody would want to change, "parameters" for everything that run_speedy may take as an argument and "constants_runtime" for every value that has to be precalculated, probably from parameters, but is constant at runtime. Meaning we should rename the constants.jl file and constants.jl should then be loaded before default_parameters?

[white-alistair]

This topic came up again in #128.

With a growing number of parameters and constants, in particular in relation to the parameterizations, the various structs and constantly unpacking them is becoming a bit messy.

@milankl suggested an example structure like (OUTDATED see below)

struct Constants
    time_integration::TimeConstants
    parametrization::ParametrizationConstants
end

struct ParametrizationConstants
     clouds::CloudConstants
     convection::ConvectionConstants
end

as well as, potentially, some kind of @unpack_all macro for importing a specific struct of macros into a namespace.

In addition, we need to move some numbers from the Parameters struct into the Constants struct in order to avoid type promotions: #128 (comment)

Let's use this issue to do a general overhaul of how we use parameters and constants.

[milankl]

Picking this up again, with #241 we'll have the following

abstract type AbstractDynamicsConstants{NF} end
abstract type AbstractParameterizationConstants{NF} end

struct DynamicsConstants{NF<:AbstractFloat} <: AbstractDynamicsConstants{NF}
struct ParameterizationConstants{NF<:AbstractFloat} <: AbstractParameterizationConstants{NF}

While it sounds tempting to group both into Constants or something, i don't think it makes sense as BarotropicModel or ShallowWaterModel won't use ParameterizationConstants so we should keep them separate. I'm still in favour of the following distinction between parameters, coefficients, constants. While all are * constant * at runtime

• parameters are user-facing, have a default value but can be changed through arguments to initialize_speedy, and define together with PrognosticVariables the model run completely.
• coefficients are bundled parameters, to be used (mostly) within the same function/algorithm; e.g. we have the MagnusCoefficients for the calculation of saturation vapour pressure
• constants face the dynamical core / parameterizations, are fully determined by all parameters/coefficients, may include some precalculation (e.g. the scaled time step which is not chosen directly as parameter) and conversion to a given number format.

So schematically we have

• user -> parameters + coefficients -> constants -> dynamical core / parameterizations