Feature #1402 config cleanup model applications

[georgemccabe]

This PR involves cleaning up the METplus config files in the repository under parm/use_cases/model_applications.

I also added support for setting match_points in TCPairs wrapper because it was being set via TC_PAIRS_MET_CONFIG_OVERRIDES in a few use cases.

Pull Request Testing

• Describe testing already performed for these changes:
  

Ran existing use cases and confirmed there were no differences

• Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:
  

Ensure all automated tests pass
Review config files to ensure organization of variables is satisfactory and all URLs to documentation are correct

• Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes]

• Do these changes include sufficient testing updates? [Yes]

• Will this PR result in changes to the test suite? [No]
  

• Please complete this pull request review by 8/2/2022.
  

Pull Request Checklist

See the METplus Workflow for details.

• Add any new Python packages to the METplus Components Python Requirements table.
• Review the source issue metadata (required labels, projects, and milestone).
• Complete the PR definition above.
• Ensure the PR title matches the feature or bugfix branch name.
• Define the PR metadata, as permissions allow.
  Select: Reviewer(s)
  Select: Organization level software support Project or Repository level development cycle Project
  Select: Milestone as the version that will include these changes
• After submitting the PR, select Linked issues with the original issue number.
• After the PR is approved, merge your changes. If permissions do not allow this, request that the reviewer do the merge.
• Close the linked issue and delete your feature or bugfix branch from GitHub.

[j-opatz]

Should these options (e.g. TC_PAIRS_INIT_INCLUDE, TC_PAIRS_VALID_BEG, etc.) be removed if they're just being set to default (aka empty)? That seems to be more in line with how the other use cases are being handled.

[j-opatz]

Many of the TC_STAT options are empty here as well; seems to be common for the feature relative use cases. Should these be removed for ease of reading, or are they popular/integral to users and should stay?

[j-opatz]

I left two comments related to the feature relative cases, but they are not necessary changes to my approval of the PR. All of the links that I tested worked, and the rearrangement of the use cases, while a vast undertaking, helps create a natural order to the config files that will hopefully help users dive into these use cases easier.

[georgemccabe]

@j-opatz , thank you for bringing up the variables with empty values. While going through these changes, I removed many of the empty string values to discover any variables that are required when they should be optional. If any were found, I would update the wrapper to no longer require these variables. It appears I may have missed these few variables, so it would be good to remove them and test to ensure that the same result occurs. I can do this in a separate branch.

This can get tricky, as there are some MET config variables where the default is a list with a single value and an empty list is a valid value for that variable. In this case, the behavior will differ if the METplus variable is unset vs. if it is set to an empty string, so removing the variable would change the results by design. This is unlikely the case for these variables.