Add RUC LSM support

[grantfirl]

The main purpose of this PR is to add support for the RUC LSM and provide at least one case that can be used to run it. The following work has been done:

• Add a new gabls3_ruc case that has soil moisture profile tuned to provide an initial Bowen ratio of 1/3 when using RUC LSM as part of the SCM_GSD_v1 suite
• retune gabls3 cases used with other LSMs to account for code changes in those schemes since the original gabls3 cases were added
• add a new lsm_cold_start variable to replace the use of (.not. flag_restart) for RUC LSM; this allows the SCM to keep flag_restart = .false. (since other schemes use this and the SCM is not restartable) but set lsm_cold_start = .false. when there is initial conditions data available to start any LSM (but specifically RUC LSM)
• rearrange code in scm_input.F90 and scm_type_defs.F90 to match the order of variable declarations in GFS_typedefs.F90 (should make it easier to read and compare with GFS_typedefs in the future to notice any discrepancies)
• added new output for LSMs in scm_output.F90
• updated scm_type_defs.F90/physics_set for LSM initialization to match latest code in FV3GFS_io.F90

[tanyasmirnova]

@grantfirl The changes look good to me.

[grantfirl]

@mkavulich The ccpp-physics pull request for which this is based has been merged. Would you please review this?

[climbfuji]

Great to see RUC LSM working in SCM!

[mkavulich]

Sorry, I only had time to look over some of the code before it was merged. Just curious, what was your thinking behind the reorganization of the variable declarations, reads, etc. in scm_input.F90 and scm_type_defs.F90? I don't quite get how they are organized.

[grantfirl]

Sorry, I only had time to look over some of the code before it was merged. Just curious, what was your thinking behind the reorganization of the variable declarations, reads, etc. in scm_input.F90 and scm_type_defs.F90? I don't quite get how they are organized.

No problem. We only need one CODEOWNER approval to merge.

The reorganization is not a big deal, but the order with which variables (surface variables in particular) are listed and read in better matches the order in which they appear in GFS_typedefs.F90. This is a good thing for future maintenance because often physics developers work only in FV3 and change which variables are needed as input by schemes within the FV3 version of GFS_typedefs.F90. During SCM updates to ccpp-physics, the first thing that is done is a diff between the FV3 and SCM versions of GFS_typedefs.F90 to bring over changes. Sometimes, similar changes need to happen within the SCM code (input), and it is just easier to know what to change if orders in the SCM code match what is in GFS_typedefs.