Refactoring for snow thermal conductivity

[ekluzek]

There's some refactoring that would be useful to do to the snow thermal conductivity code. This code chooses between Jordan and Sturm currently. The code is cut and paste into locations it's needed rather than handled in a modular way where it's in one place with appropriate calls. So refactoring helps with maintainability, extensibility, and robustness.

For modularity and keeping data limited to where it's needed I'd want to move the namelist items to the modules that use them. This allows science code to be replaced and NOT affect other unrelated CTSM code, as well as restrict where it can get messed up. So move snow_thermal_cond_method and snow_thermal_cond_glacier method from controlMod to a ReadNML subroutine in SoilTemperatureMod. And move snow_thermal_cond_lake_method to a ReadNML subroutine in LakeTemperatureMod.F90.

The other problem is that now we have Jordan and Sturm code and strings copied in various places around the code, and we really want to have a "Snow_Thermal_Conductivity" class that handles it. An OO class would allow for the two options to be chosen without adding logic to handle them both throughout the code. And it prevents the maintenance of magic strings and copied code all around. So we would have the assurance that we've caught all the places that needed to change as it's only a single place, instead of these three places. We also don't want to propagate a habit of more cut and paste of this code if it's needed in new places in the code as well in the future. We also don't really want the endrun error check to be done for every timestep for every column, as that should be done once at initialization. And finally the Sturm constants are all single precision and for reproducibility we should update them to double, but that will likely change answers.

Also there is an endrun call when a bad option is chosen that's done over every gridcell and time-step which should be done at initialization. This could have an impact on performance.

Originally posted by @ekluzek in #3072 (review)

Definition of Done:

• Develop a design document to describe how this should look
• Change the namelist variables
• Move to an OO design where snow thermal conductivity is in a class
• Unit testing of the class
• Functional testing of the class? This might help to understand how it interacts...
• Normal testing to bring in as a b4b change

[ekluzek]

@billsacks points out here the solution doesn't HAVE to be an OO one, which is certainly true. The OO solution is one I want to endorse though for other reasons. We are using it elsewhere, and by extending an abstract OO class with new class extensions you can have an arbitrary number of options and add and delete them as needed. And it keeps the logic just inside the OO factory, rather than in the driver code.