Add field for CF equivalent name

[mkavulich]

Description

This PR updates the XML, schema file, and Metadata files to include and "Equivalent CF name" field, to make it easier for code bases such as JEDI that need to interface with both CF standard names and ESM standard names.

In this process I also found and removed some duplicate names, and moved some names to better sections

Issues

Resolves #108

[climbfuji]

At first, I was confused of seeing cfname entires when they were identical to the ESM standard name, but I realized that this makes sense. Thanks for weeding through the CF names and adding the matches here.

[svahl991]

So let me confirm my understanding with this PR:

• Not every ESM name has an equivalent CF name
• Not every CF name has an equivalent ESM name
• Where there is an equivalence, it must be one-to-one

Is there code in place somewhere to enforce the last statement? Put another way, is there anything (other than human diligence) to prevent someone from accidentally pointing a new ESM name at a CF name that is already pointed to by another ESM name?

[mkavulich]

@svahl991 You bring up a good point, we should have an automated check for duplicate "cfname" elements, since there should never be duplicates in our dictionary unless we have messed something up. I was going to add a quick check in this PR, but it turns out our current tests aren't in very good shape (#144), so I would like to open a new PR to address this.

[mkavulich]

@svahl991 I have opened #145 that includes a check for duplicate CF names, which should run automatically with each PR.

And with regards to your other questions, I think your understanding is in line with my thinking. The CF names do not cover all our use cases, and we have not "automatically" pulled in all CF names (though we likely would if they were needed).

[mkavulich]

I'll also note for the record, most ESM names are identical to the equivalent CF names, but a few are different because of divergence decisions we've made in the past few years (e.g. air_potential_temperature vs. potential_temperature_of_air) or other reasons that are unclear to me (e.g. stratiform_cloud_area_fraction_in_atmosphere_layer vs. nonconvective_cloud_area_fraction_in_atmosphere_layer). It is possible that some of my equivalence additions here are incorrect due to subtle definition differences but I've done my best to ensure they are used the same, at least in CCPP.

[nusbaume]

Thanks for bringing this in @mkavulich! I had a couple questions which came up while reviewing the PR, but otherwise everything looks good to me.

[nusbaume]

I realize this isn't directly related to this PR, but is this variable any different from lwe_thickness_of_surface_snow, which is listed farther down?

[nusbaume]

I could definitely be wrong as I am not a Markdown expert, but should this have quotations marks like the standard name and type outputs? For example:

Suggested change

	snl.write(f" * Equivalent CF name: {item.text}\n")
	snl.write(f" * `Equivalent CF name`: {item.text}\n")