A list of atm2lnd and lnd2atm variables that's initialized by the CTSM, affects SLIM output

[slevis-lmwg]

I encountered this while working on #46. I reported it in the PR's issue #44, as well as in the code as follows:

    ! TODO slevis SLIM: Eliminating next assignment returns error:
    ! Longwave down is <= 0, while eliminating and then changing the
    ! initialization of t_rad_grc to tfrz in lnd2atmType works but changes
    ! answers throughout, including in MML variables. See
    ! /glade/scratch/slevis/ERS_D_Ld60.f19_g16.H_MML_2000_CAM5.cheyenne_gnu.clm-global_uniform_g16_SOM.C.20221207_111523_9gqwvp/ERS_D_Ld60.f19_g16.H_MML_2000_CAM5.cheyenne_gnu.clm-global_uniform_g16_SOM.C.20221207_111523_9gqwvp.clm2.h0.0001-03-02-00000.nc.cprnc.out
    do g = bounds%begg,bounds%endg
       lnd2atm_inst%t_rad_grc(g) = sqrt(sqrt(lnd2atm_inst%eflx_lwrad_out_grc(g)/sb))
    end do

• I will disentangle such SLIM variables from their CTSM counterparts.
• Answers will change. I hope not much and mostly (or only) in the beginning of simulations.
• I will complete this before removing remaining pieces of the CTSM that SLIM doesn't need (#60), so that I can rely on bit-for-bit testing against a baseline. For example, currently answers change when I remove code that affects the subgrid heterogeneity and they shouldn't because SLIM only uses grid cells (not landunits/columns/patches).

[slevis-lmwg]

Variables that have changed answers when I removed their ctsm copies: t_rad, albd, albi, h2osno due to the timing of their CTSM vs. SLIM initialization (as far as I can tell).

Other than changing answers, it seems to work to initialize these variables on the CTSM side and remove all other calculations for them on the CTSM side.