Create env_postprocessing.xml in case root

[mnlevy1981]

The contents of this new file are based on a config file in CUPiD (cime_config/config_tool.xml) that is comparable to a component's config_component.xml file

I will mark this as ready for review after I've had a chance to run test suites and fix any issues raised by those tests. For example, if there is no tools/CUPiD/cime_config/config_tool.xml then it raises the following error:

ERROR: Makes no sense to have empty read-only file: /glade/work/mlevy/codes/CESM/cesm3_0_alpha05d/tools/CUPiD/cime_config/config_tool.xml

[ Description of the changes in this Pull Request. It should be enough
information for someone not following this development to understand.
Lines should be wrapped at about 72 characters. Please also update
the CIME documentation, if necessary, in doc/source/rst and indicate
below if you need to have the gh-pages html regenerated.]

Test suite:
Test baseline:
Test namelist changes:
Test status: [bit for bit, roundoff, climate changing]

Fixes [CIME Github issue #]

User interface changes?:

Update gh-pages html (Y/N)?:

[jedwards4b]

Here I think that you want to make sure POSTPROCESSING_SPEC_FILE exists before you create an EnvPostprocessing object.

[jedwards4b]

Perhaps @jasonb5 should review this and provide guidance on how it might make better use of #4271.

[billsacks]

Perhaps @jasonb5 should review this and provide guidance on how it might make better use of #4271.

I was just thinking about #4271 in a different context, so thought I'd post some questions here in case there's consideration of leveraging that here:

• Do we actually use anything from Remove provenance/model specific configuration #4271 currently in CESM? In particular, I see that @jasonb5 provided a cesm_config.py file, but I don't see that anywhere
• If I understand the code from Remove provenance/model specific configuration #4271 correctly, it seems like it expects to find any extensions in the cime_config directory. For CESM, though, to avoid duplication between our various top-level repositories (CESM, CAM, CTSM, etc.), each of which have their own cime_config, I'm thinking we'd want to put these extensions in ccs_config, which is shared between these top-level repositories. I'm wondering about the feasibility of having that flexibility. For example, could the location of this customize location be provided in config_files.xml?