pass all CO2 fields in CO2 emissions compsets with CAM7

[klindsay28]

Description of changes

Pass all CO2 fields in CO2 emissions compsets with CAM7.
This is done by setting CCSM_BGC=CO2C.

Specific notes

Contributors other than yourself, if any: none

CMEPS Issues Fixed (include github issue #):
There is not a corresponding CMEPS issue for this.

Are changes expected to change answers? (specify if bfb, different at roundoff, more substantial)
Answers change in CO2 emissions compsets with CAM7, which are
under development and not in use yet.

Any User Interface Changes (namelist or namelist defaults changes)?
Changes flds_co2c to '.true.' in CO2 emissions compsets with CAM7.

Testing performed

ERS_Ld5 and SMS_D_Ld2 tests in an 1850 CO2 emissions compsets with CAM7 pass
on derecho-intel.
Testing was done with branches in development of CAM, CTSM, and MOM6 that enable
CO2 emissions.

[billsacks]

Can you explain why there is a move away from use of the BGC component of the compset long name? I have a few concerns with this new convention... I realize that this convention is already being used in compset long names so maybe this ship has sailed, but I'd still like to better understand it and consider whether it really makes sense.

I see that CSEG discussed this about two years ago (raised by @ekluzek ) and I raised this concern then, too. I'm not sure what happened following that point... I assume there was a breakdown in communication: https://docs.google.com/document/d/186U6-dt_wWZZGU9NzYQ5zNlMnpx9XX6oweuTXzQY-oo/edit?tab=t.0#heading=h.xjh4bj6ux171

If you weren't involved with this decision, I'd like to engage others here. If possible, I'd really like to change these long names to follow a more robust convention.

Some of my concerns are:

(1) It appears that there are now multiple ways to do the same thing, which generally feels problematic and error-prone (e.g., if current or future logic is written to handle one but not the other mechanism).

(2) It appears that a 'C' or 'E' is put at the end of the time period. As far as I know, there are no restrictions on the naming of the time period, so there could later be a time period designation that accidentally ends with C or E, triggering this logic.

(3) The match here only works with CAM7. What about DATM or other compsets? Building a robust match seems difficult with C/E at the end of the time period, which is part of why I'd prefer to see it in the BGC modifier if possible.

(4) Other components will need a similar change - e.g., there's the following in CTSM:

  <entry id="CLM_CO2_TYPE">
    <type>char</type>
    <valid_values>constant,diagnostic,prognostic</valid_values>
    <default_value>constant</default_value>
    <values>
      <value compset="_CAM"        >diagnostic</value>
      <value compset="_BGC%BDRD"   >diagnostic</value>
      <value compset="_BGC%BPRP"   >prognostic</value>
      <value compset="HIST.*_DATM" >diagnostic</value>
      <value compset="SSP.*_DATM"  >diagnostic</value>
    </values>
    <group>run_component_ctsm</group>
    <file>env_run.xml</file>
    <desc>Determines how CLM will determine where CO2 is set.
      If value is constant, it will be set to CCSM_CO2_PPMV,
      if value is either diagnostic or prognostic, the atmosphere model
      MUST send it to CLM. CLM_CO2_TYPE is normally set by the specific
      compset, since it HAS to be coordinated with settings for the
      atmospheric model. Do not modify this variable. If you want to modify for
      your experiment, use your own user-defined component set
      This is an advanced flag and should only be used by expert users.</desc>
  </entry>