Updates for GEOS-JEDI Work

[mathomp4]

This PR updates GEOSgcm to use:

• FMS geos/2019.01.02+noaff.10
• fvdycore geos/v2.9.0
• GOCART sdr_v2.2.1.2

The FMS and FV updates are from @climbfuji and @cmgas who are working with @rtodling on getting GEOS and JEDI to work happily with each other. These updates provide the feature to point FMS/FV to a non-standard input.nml location. (@climbfuji can say more if I have that wrong).

The GOCART update is needed because, as found by @climbfuji, if you build GEOSgcm, you get three sets of CMake files for doing find_package: MAPL, GEOSgcm, and GOCART. This then causes circular dependencies as GOCART requires things "provided" by GEOSgcm and GEOSgcm requires GOCART. So the sdr_v2.2.1.2 tag is an update off of sdr_v2.2.1.2 (changes), echoing a similar PR doing the same to GOCART develop (see https://github.com/GEOS-ESM/GOCART/pull/273). The changes are purely in the CMake trying to detect if GOCART is being built standalone, or as part of GEOS.

All my testing with GEOS in both AMIP and Coupled MOM6 shows this is zero-diff both state and history (and for MOM6, MOM diagnostic output).

[cmgas]

@mathomp4 does this also use your branch feature/mathomp4/test-no-standalone-dev of GOCART?

[mathomp4]

Crap. The GCM runs are failing.

[mathomp4]

@mathomp4 does this also use your branch feature/mathomp4/test-no-standalone-dev of GOCART?

ooh. No it does not. Do you need that for your runs?

[cmgas]

We need it to build with JEDI later, yes

[mathomp4]

We need it to build with JEDI later, yes

Ooof. Okay. That means I might need to work with @sdrabenh to backport that change to the version of GOCART currently in use here. GOCART develop is non-zero-diff so we can't take that yet.

But first: fixing the CI issue

[mathomp4]

I think I have the fix for the FMS issue. And I'll work on the GOCART issue as well.