Include detailed description/specification of `kind` properties; particularly the use of `kind_phys`

[mkavulich]

Per discussion around whether the ESM Standard Names should include information about variable kinds, it was decided that better documentation is needed for how kind is specified and used within the CCPP, and the tech doc seems like the best place for this. This documentation should include the use of kind_phys as a standard physics kind in CCPP and how variable kinds should be parameterized within physics schemes.

[grantfirl]

It seems to me that we should allow for at least three different real kinds:

1. kind_soft - that can be controlled by the host or compile flags (should be the vast majority of real physics variables)
2. kind_firm_single - for variables that must be kept in single precision
3. kind_firm_double - for variables that must be kept in double precision

[gold2718]

@grantfirl, what's wrong with using standard names for fixed sizes?

1. kind_phys: Flexible, set by host build system as it does now
2. REAL32: ISO defined name for a 32-bit IEEE real
3. REAL64: ISO defined name for a 64-bit IEEE real
   See https://fortranwiki.org/fortran/show/iso_fortran_env

[grantfirl]

@gold2718 Good point, I suppose that we don't really need to redefine single and double. I guess the main point we need to make is that developers should think more carefully about real kinds. If all physics developers specified which variables/calculations actually need to be in double-precision, we wouldn't have the current situation of having to reverse engineer it to enable "single precision" physics suites (AKA "minimally-double precision" physics suites). The soft/firm language is an attempt to signal from a developer that, "yes, this really needs to be this type" and not "I chose kind_phys because that's what all other schemes are doing and the documentation said to do that".