Add optional metadata fields for constituent implementation

Description

For the purposes of completing the constituent infrastructure in CAMDEN, @gold2718 and I propose two new optional metadata fields:

• molar_mass (float)
• input_names (list): list of aliases found on file for reading input data file

Additionally: a new interface will be generated (akin to ccpp_physics_suite_variables) that will return the input_names list for each variable.

Aside: a related optional metadata field is already in NCAR/ccpp-framework/main:

• advected (boolean, default false): if true, this is an advected constituent

Alternatives (optional)

During discussion of this at the CCPP Framework meeting, there was some pushback on the input_names field because:

1. "non-standard" fieldnames like "T" and "state_T" (for example) introduce unwanted ambiguity
2. Since the framework should have nothing to do with I/O it seems iffy to include these names that are very much tied to I/O

One related suggestion was to change the name of the field from input_names to known_aliases or input_aliases for clarity. Though this does not resolve the ambiguity of the aliases themselves or the I/O ties.

Start by locating the constituent metadata handling and the existing ccpp_physics_suite_variables interface mentioned in the issue. Resolve whether input_names belongs in the framework and what its name and semantics should be, then define the generated interface and verify that molar_mass, input_names, and advected are represented consistently.