Run CI in Docker containers

[RobertPincus]

This PR includes a set of Dockerfiles to create Docker containers with all the software needed to run the continuous integration and a change use those containers in the CI.

We could merge now and then make another PR to to include tests of RTTOV in the CI, or Jonah could work on .github/workflows/containerized-ci.yml now and we make a single PR.

Will we retain the bare-metal CI once we're using containers? Do we want to extend this to include other compilers?

@jshaw35 @dustinswales @alejandrobodas

[jshaw35]

@RobertPincus great work! I am interested in understanding some of the details when there is time. Essentially, how is this different from the containerized CI that existed previously?

I say pull this in and I'll create a new PR for the RTTOV testing. It looks like there are containerized gfortran and ifx now so COSP-RTTOV can be tested in both of them?

[RobertPincus]

@jshaw35 This PR changes to Docker containers built from files in the COSP repo rather than relying on containers built for another purpose. That means both that we don't need to install the Python packages on the fly. More importantly the COSP containers include the RTTOV libraries in /usr. This means you can modify the containerized-CI to exercise the RTTOV integration.

Another change is that gfortran is now being tested in the containers, so maybe we don't have to run the bare-metal CI any more.

[RobertPincus]

Mmmm @alejandrobodas @jshaw35 We are using the same KGOs for all compilers, and it looks like difference using ifx/OneAPI are larger than tolerances allow for?

[jshaw35]

@RobertPincus, I agree this looks like a compiler change.

As a note, the dbze94 variable has often appeared to be the most susceptible to compiler changes. This makes me wonder if this has something to do with the code itself.