Use CMIP variable naming conventions across interface when possible

[mnlevy1981]

For tracers, we should use variable names out of

http://www.geosci-model-dev-discuss.net/gmd-2016-155/

and the driver can convert these variable names to maintain backwards compatibility in history output. Some of the surface forcing fields MARBL will be requesting have standardized names as well.

In the paper, variable names are found in tables beginning on page 33.

[mnlevy1981]

As we discussed at the Aug 15 meeting, this is not going to be done with the surface forcing / tracer refactor -- the CMIP6 naming convention has some inconsistencies that we would like to avoid and also does not necessarily provide a name for every tracer / forcing we may be passing through the interface. A better option will be to revisit this issue in the future and determine at that point what naming convention makes the most sense.

@matt-long raised two points:

1. Besides the surface forcing and tracers, we will want to apply this naming convention to diagnostics as well.
2. The flux coupler in CIME may provide a good starting point if we want to start from scratch and write a new convention*. Specifically, the name of the coupler field explicitly categorizes variables as 'state' or 'flux' and that differentiation would be useful (on the down-side, it is not always clear what a new variable should be called in the coupler)

* Obligatory XKCD: http://www.xkcd.com/927/

[mnlevy1981]

MOM is using the CMOR field name for its output (where available), so at the very least we should add a cmor_name field to marbl_tracer_metadata_type (for now, I'll just have MOM use short_name)