These options are incompatible.

Partially addresses ESCOMP#502

Also, fix error checks involving use_subgrid_fluxes in CLMBuildNamelist:
previously, subgridflag was not set at the point when the error checks
involving that value were being done; I have fixed that by always
including use_subgrid_fluxes in the default namelist.

Resolves ESCOMP#502

Testing:
SMS_D_Ld1_P4x1.f10_f10_musgs.I2000Clm50BgcCropQianRsGs.bishorn_gnu.clm-default
passes and bit-for-bit

This will facilitate upcoming refactoring

Testing:
SMS_D_Ld1_P4x1.f10_f10_musgs.I2000Clm50BgcCropQianRsGs.bishorn_gnu.clm-default
passes and is bit-for-bit

This will facilitate upcoming refactoring

Make oldhyd inherit from default so that it has some output in a one-day
test

I plan to use this for testing on my laptop, specifically with the test:

SMS_D_Ld1_P4x1.f10_f10_musgs.I2000Clm45BgcCropQianRsGs.bishorn_gnu.clm-oldhyd

This will be done differently for different snow cover methods, so it
will be part of the snow_cover_fraction polymorphic class.

This will be called from SnowCompaction, too

There was a minor difference between the formulation in SnowCompaction
and the one in FracSnowDuringMeltClm5: the latter has an extra min
statement. It looks like this shouldn't change answers (the min
statement shouldn't be necessary, given the min that is already applied
to smr), but it's possible that it will change answers by roundoff in
rare cases.

This isn't actually used yet in the code, and the two most important
methods are just stubs.

I needed to move it out of SnowHydrologyMod because it will now be used
in SnowCoverFractionMod. I thought about reading it in in the factory
method in SnowCoverFractionMod, but I prefer having this (and other
similar control flags that we might need in the future) in clm_varctl
for a few reasons:

- It avoids introducing a whole new namelist group and a new namelist
  read routine just to hold and read this one variable

- It makes the interface of the factory method more clear, in that we'll
  pass in the method directly

- I like the idea of having these big controls (determining relatively
  big parameterizations) all be in one namelist group for the sake of
  build-namelist: we can ensure that we read this namelist group first,
  then do some other logic based on things set there (see also
  ESCOMP#26 (comment))

We still have to move some code from SnowHydrologyMod into
SnowCoverFractionMod for the N&Y07 method

Move the code out of SnowHydrologyMod, into SnowCoverFractionMod

It's clearer to have the error check more closely associated with the
relevant code.

I have confirmed that, in clm4_0_00, the update of snowdp looked like:

          dz_snowf = qflx_snow_grnd_col(c)/bifall
          snowdp(c) = snowdp(c) + dz_snowf*dtime

Also fix build-namelist error checking of compatibility with
use_subgrid_fluxes

This fixes the error on cheyenne_intel related to trying to allocate an
array (n_melt) that is already allocated.

This tests that adding water isotopes does not change answers

This is not yet passing

1. Make 'base' case have water isotopes on. This way the baselines
   include water isotopes, which is nice for having stronger baseline
   comparisons.

2. For now, use enable_water_tracer_consistency_checks rather than
   enable_water_isotopes. I hope to revert this later, but this seems
   needed for now in order for the test to run to completion.

Resolves ESCOMP#571

This covers some code that isn't covered by any existing tests (such as
the oldhyd test), though the amount of additional code coverage is
small, so we don't necessarily need to keep this test long-term.

Resolved Conflicts:
	cime_config/testdefs/testlist_clm.xml
	src/main/controlMod.F90

Requested by @ekluzek

This has the theoretical potential to change answers under the following
conditions:

- Now frac_sno is being explicitly reset to 0; before, under some
  conditions (h2osno_total > 0, but snow_depth <= 0), frac_sno would
  remain at its old value.

- If h2osno_total or newsnow are ever negative, we could have different
  answers

A one-day
test (SMS_D_Ld1_P4x1.f10_f10_musgs.I2000Clm45BgcCropQianRsGs.bishorn_gnu.clm-oldhyd)
is still bit-for-bit; I'll run a 3-year test next.

This is from Swenson & Lawrence 2012

Sean Swenson and others suggested using these longer names rather than
the more cryptic short abbreviations. Part of the motivation is once we
have 4 separate files, this will make the science modules stand out more
because of their longer names.

I wanted to name the namelist group scf_SwensonLawrence2012_inparm for
consistency with the namelist option, but this didn't work with the
namelist generation scripts, presumably because of the capitalization;
so I'm using the all-lowercase form, scf_swenson_lawrence_2012_inparm.

Based on discussion today, we want to follow this approach. (See
<https://github.com/ESCOMP/ctsm/wiki/Meeting-Notes-2019-Software#august-5-2019-special-meeting-on-design-of-snowcoverfractionmod>.)

Since the init method is only called from the factory method, it's
fairly straightforward to allow the different init methods to have
different interfaces, rather than having a bunch of unused arguments in
some of the methods. The big motivation here is avoiding the need to
change all parameterizations' Init methods if you add a new
parameterization with a new input requirement.

This ended up being a little non-trivial because of the need for the
select type statement. I think we could have avoided that if we did all
initialization in the constructor (avoiding an Init method
entirely). But we have had some compilers (e.g., intel17) that don't
seem to work right with function constructors, so for now we're sticking
with an Init subroutine.

Sean Swenson pointed out that it would be better to put the science up
front.