NUOPC Cap for MOM6

[JessicaMeixner-NOAA]

This is the NUOPC cap for MOM6. This is the unified version that resolved the differences from EMC and NCAR. (It's redoing PR#898 because I needed to make it from a different branch).

[Hallberg-NOAA]

This looks like a valuable new addition to MOM6. Thanks for to all who contributed to this new capability.

There are a few code-style issues that I would like to raise concerning this commit.

1. All MOM6 module use statements are supposed to have the "only" attribute and then list the specific elements of the module that are being used. Taking the lazy approach of just having a module use statement is dangerous (if two modules have the same procedure, you might accidentally get the wrong one) and uninformative for people trying to read the code. (I hear that the MOM6 debugger's guild has it in their union work rules that they will not debug any code that does not use "only" in its module use statements!)

2. All MOM6 subroutine arguments and defined-type elements are supposed to have doxygen comments describing the argument or element along with units and any sign-conventions. Some of the new code modules have these throughout, others have comments with the right information but not doxygen syntax, and some have no comments at all describing the arguments to some routines.

3. All MOM6 subroutines and defined types are supposed to have doxygen that briefly describe them and what they do. When you generate doxygen documentation of code, there is a log file that lists all elements and modules that are not documented, which can be very helpful for ensuring that nothing is missed. (Please see https://github.com/NOAA-GFDL/MOM6/wiki/Doxygen for a discussion of the use of doxygen with MOM6.

4. It is preferred that the "implicit none" and "private" statements for MOM6 modules be on the same line separated by a semi-colon ("implicit none ; private") to facilitate searches to detect modules that do not have both statements.

These may seem like are relatively minor things, but they do make a difference for the readability and automatically generated code documentation. We will be adding automated tests to the code used at GFDL to ensure that these code-standards are adhered to (with recent updates it now does), and even though we at GFDL do not yet have a way to test the new NUOPC driver code, we think that it would be strongly advisable to follow the same standards.

[adcroft]

Testing pipeline: https://gitlab.gfdl.noaa.gov/ogrp/MOM6/pipelines/7592

[adcroft]

@gustavo-marques This PR is onto dev/master so should be evaluated by NCAR. Since it only affects files in config_src/nuopc_driver/ I believe you alone acutally run tests that might be affected. In this case I think we do not need @awallcraft or @kshedstrom to test this PR.

Although we don't exercise the code this PR is now passing the tests on Travis when I merge into dev/gfdl and dev/master.

[gustavo-marques]

We approve this PR.