Workflow to handle JEDI updates

[mranst]

Today we discussed how to handle pinning new versions of JEDI for swell. Currently, switching builds of JEDI requires one of us to create a new build using jedi_bundle and open a PR to swell to switch the versions. With the comparison tests introduced to tier2 application tests, new builds are being created and tested every night. We could set up a system that automatically switches to the new build of JEDI on a daily or weekly basis assuming zero diff.

We currently use residual norm as the basis for zero diff for variational suites, though we need different metrics for ensemble cases, with min, max, and RMS tables seeming to be the best option.

Related issue - using NCCS dataportal to display comparison test results and plots. I will email support about setting this up.

[mranst]

I've opened a few PRs to chip away at this issue. The concept is to switch the build of JEDI to the one that's created as a part of nightly tier2 testing. When a new build passes with zero diff, it is set as the new stable version, and the experiments generated for that night become the new basis of comparison. If the tier2 tests fail for any reason, the stable run remains the same, and the text and plots from the comparison are posted to dataportal.

Relevant PRs:
#704 - Updates the pinned version to the latest stable build.
#702 - Adds a task to publish the results to dataportal
GEOS-ESM/CI-workflows#30 - Enables this to happen through the tier2 tests.

Issues:

• We need a way to compare ensemble experiments, I've looked at the JEDI output log for localensembleda and see the tables with min, max, and RMS, but there seems to be a lot of them that I can't distinguish from each other. I could use some guidance on how to set up the comparisons for these.
• Maybe some kind of comparison for cf/hofx experiments?