Update Namelist documentation for all namelist options

[christinaholtNOAA]

Several UFS Apps use undocumented namelist settings in the UPP Read the Docs documentation. Specifically, I made these changes:

• Added explanations for all namelist options used in the UPP code, and based the descriptions on the comments in the code where they were available.
• The additions follow the documentation style of the ufs-weather-model namelist documentation. That means each entry is displayed in a table format, and information about type and default value is included.
• I modified the style of the rst file to use long lines in paragraphs instead of wrapping, consistent with @gspetro-NOAA's documentation style preferences for supportability. Specifically, when diffs are proposed in PRs, GitHub's highlighting will draw the eye to exact differences made without concern for re-wrapping lines.
• I updated the EMC URL because it failed during the docs build.

Fixes Issue #949

[WenMeng-NOAA]

@christinaholtNOAA Can you open a new UPP issue at here to link this PR?

[WenMeng-NOAA]

@christinaholtNOAA Can you sync your branch with the latest UPP develop?

[christinaholtNOAA]

Sorry I am falling behind on your requests. I will open the ticket, apply the suggested changes, and update the branch by tomorrow. Thanks for guiding me through the process.

[christinaholtNOAA]

@gspetro-NOAA, I am curious if you'd be okay with a standardized lowercase-only set of variables. Given that the capitalization strategy of these variables doesn't seem to have a rhyme or reason and that Fortran doesn't care, it seems like it might be more readable for users trying to get their namelists "right."

[gspetro-NOAA]

@christinaholtNOAA I think my main concern is just that the variables appear in the UPP code later in camel casing. I'm not sure what impact, if any, lowercasing things would have down the line. Lowercasing seems beneficial for uniformity and readability, but less expert users might be confused if later on they see camel-cased variables. So I can see plusses and minuses for both. @WenMeng-NOAA @FernandoAndrade-NOAA do you have any opinion?

[FernandoAndrade-NOAA]

@christinaholtNOAA I think my main concern is just that the variables appear in the UPP code later in camel casing. I'm not sure what impact, if any, lowercasing things would have down the line. Lowercasing seems beneficial for uniformity and readability, but less expert users might be confused if later on they see camel-cased variables. So I can see plusses and minuses for both. @WenMeng-NOAA @FernandoAndrade-NOAA do you have any opinion?

In the long run, I'd say uniformity and readability may be the bigger benefit than avoiding temporary confusion with users, even if I am partial to camel casing.

[christinaholtNOAA]

@WenMeng-NOAA Do you have any thoughts here? It seems like we might be leaning for uniformity to go with lower case in the docs, if you're in agreement.

[WenMeng-NOAA]

@WenMeng-NOAA Do you have any thoughts here? It seems like we might be leaning for uniformity to go with lower case in the docs, if you're in agreement.

@christinaholtNOAA Fortran coding is case insensitive. From documentation uniformity and readability perspective, using lower case would be good.

[WenMeng-NOAA]

@gspetro-NOAA We will wrap up this PR for testing. Please let us know if you have more comments.

[WenMeng-NOAA]

@FernandoAndrade-NOAA Conducting the UPP RTs on either Hera or Orion would be sufficient.

[FernandoAndrade-NOAA]

@FernandoAndrade-NOAA Conducting the UPP RTs on either Hera or Orion would be sufficient.

Hera RTs finished, this PR should be ready for merging.