Add dependencies to metadata

[climbfuji]

This PR fixes #308 for ccpp_prebuild.py.

Changes:

• add capability to parse new, required sections starting with [ccpp-table-properties]
  • the names in the name = ... attributes for these sections cannot end with one of the predefined CCPP stages (e.g. _init)
  • the type for these sections must be the same table as the corresponding [ccpp-arg-table] sections
• remove unnecessary duplication of information in ccpp_prebuild.py's argument dictionary: instead of arguments[module_name][scheme_name][subroutine_name], use arguments[scheme_name][subroutine_name]; this is sufficient, because per requirement module_name = scheme_name
• fix a bug in src/ccpp_types.meta
• fix a warning in scripts/metavar.py by changing is to ==:

FV3/ccpp/framework/scripts/metavar.py:423: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if source.type is 'SCHEME':

Associated PRs:
earth-system-radiation/rte-rrtmgp#85
#317
NCAR/ccpp-physics#483
NOAA-EMC/fv3atm#153
ufs-community/ufs-weather-model#180

See ufs-community/ufs-weather-model#180 for regression testing.

[climbfuji]

@gold2718 @grantfirl @ligiabernardet @llpcarson please have a look at this attempt to implement the CCPP scheme dependencies in the metadata.

@gold2718 since your version of the metadata parser metadata_table.py has advanced, and since the old version used in the master branch works in conjunction with ccpp_prebuild.py's metadata_parser.py, we are more or less free how to implement this under the hood. As long as the input (see suggested format in the ccpp-physics PR NCAR/ccpp-physics#483) is the same for ccpp_prebuild.py and cap_gen.py, we are good.

[gold2718]

add capability to parse sections starting with [ccpp-table-properties]

It seems that this section is required, can that be added to the statement above? (e.g., 'parse required sections')

[climbfuji]

add capability to parse sections starting with [ccpp-table-properties]

It seems that this section is required, can that be added to the statement above? (e.g., 'parse required sections')

Done.

[climbfuji]

@grantfirl @llpcarson @gold2718 please review this PR, if possible. @ligiabernardet @JulieSchramm please also take a look for your information and future documentation updates

[llpcarson]

This looks OK to me, relying on the tests to confirm (vs code inspection!)

[grantfirl]

I didn't find anything obviously amiss. Nice job on the implementation!

[climbfuji]

@gold2718 I will need to merge this now in order to not hold back the UFS, sorry.

[gold2718]

@climbfuji, Sorry for not getting through this. To be honest, I do not understand the code and have been struggling to get through it.
I'll take another look but as long as we agree on the semantics, it should be okay in the long run.

[climbfuji]

@climbfuji, Sorry for not getting through this. To be honest, I do not understand the code and have been struggling to get through it.
I'll take another look but as long as we agree on the semantics, it should be okay in the long run.

Thansk @gold2718 - that was my understanding, too. As long as the input (semantics) and the output (functional code) are correct, it shouldn't matter. Once we switch to cap_gen.py, you will understand the code, hopefully I will, too.