Fix for DGLC with SLND

[billsacks]

Description of changes

Only average FBlndAccum2glc_l if the field bundle was created

This is needed to fix some failing tests with DGLC and SLND in the aux_cdeps test list:

• SMS_Ly3.f10_f10_ais8gris4_mg37.2000_SATM_SLND_SICE_SOCN_SROF_DGLC%NOEVOLVE_SWAV.derecho_intel
• SMS_Ly3.f10_f10_ais8_mg37.2000_SATM_SLND_SICE_SOCN_SROF_DGLC%NOEVOLVE_SWAV.derecho_intel
• SMS_Ly3.f19_g17_gris4.2000_SATM_SLND_SICE_SOCN_SROF_DGLC%NOEVOLVE_SWAV.derecho_intel

The problem seems to be that med_phases_prep_glc_avg is called unconditionally from med_phases_prep_glc, but FBlndAccum2glc_l is only created if accum_lnd2glc is true. (Note that prep_glc_accum_lnd, which is another place where FBlndAccum2glc_l is used, is called if lnd2glc_coupling or accum_lnd2glc are true.)

(Prior to cmeps1.1.48 the similar code was inside a fldchk conditional, which also had the effect of skipping this code if FBlndAccum2glc_l wasn't created.)

Specific notes

Contributors other than yourself, if any:

CMEPS Issues Fixed (include github issue #):

Are changes expected to change answers? (specify if bfb, different at roundoff, more substantial) - no: bfb

Any User Interface Changes (namelist or namelist defaults changes)? no

Testing performed

With cesm at 3ff5aed:

(1) These failing tests - now pass:

SMS_Ly3.f10_f10_ais8gris4_mg37.2000_SATM_SLND_SICE_SOCN_SROF_DGLC%NOEVOLVE_SWAV.derecho_intel
SMS_Ly3.f10_f10_ais8_mg37.2000_SATM_SLND_SICE_SOCN_SROF_DGLC%NOEVOLVE_SWAV.derecho_intel
SMS_Ly3.f19_g17_gris4.2000_SATM_SLND_SICE_SOCN_SROF_DGLC%NOEVOLVE_SWAV.derecho_intel

(2) These additional tests - pass and baseline comparisons are bfb:

ERS_Ly7.f09_g17_gris4.T1850Gg.derecho_intel
SMS_Lm13.f10_f10_mg37.I1850Clm50SpG.derecho_intel
SMS_D_Ly1.f09_g17_ais8.T1850Ga.derecho_gnu
MULTINOAIS_Ly2.f10_f10_ais8gris4_mg37.I1850Clm50SpRsGag.derecho_intel.cism-change_params

(3) This additional test - passes (no baselines available):

SMS_D_Ld5.f10_f10_ais8gris4_mg37.I1850Clm50SpGag.derecho_intel.cism-test_coupling

[billsacks]

Thanks to @fischer-ncar for finding this problem.

@mvertens I'm assigning you as reviewer if that works for you. I have done a pretty careful analysis to understand the problem so I feel pretty good about this fix, but would welcome your review, including any possible suggestions of a better way to handle this.