GOCART2G_GridComp too cozy with MOIST parameterizations

There is an architecture violation in GOCART2G_GridComp where its actions depends on the cloud microphysics it is coupling to:

if((adjustl(cld_micro)/="2MOMENT") .and. (index(aeroList(i), 'SU') > 0)) then ! maintained for compatibility with the single moment
call ESMF_StateGet(state, trim(aeroList(i)), child_state, RC)
call MAPL_GetPointer(child_state, ptr_3d, 'SO4', RC)
end if

This an ARCHITECTURE VIOLATION: a component should not know about its coupling environment. A symptom manifested itself recently when a change of the names of parameterizations inside MOIST required concurrent adjustment in GOCART2G. This is very undesirable as it requires very close matching of GOCART and MOIST releases.

The general principle is that callbacks should establish a protocol for interacting with cloud microphysics but in no way it should consult the MOIST resource file to find out details that are beyond the scope of GOCART2G. This could be avoided by having separate rc files for each component, rather than single GCM rc file that is used for all components.

Start in GOCART2G_GridComp at the conditional on cld_micro and the SO4 state lookup, then inspect the callbacks and shared GCM rc-file usage described in the issue. Determine how the protocol can avoid consulting MOIST parameterization names. Done means GOCART2G no longer depends on those cloud-microphysics details while its coupling still works.