Bring ExtData2G into develop via optional build argument to cmake

[bena-nasa]

This add the next generation of ExtData as a build option to satisfy Arlindo's request to be shift development of GOCART2G to use the new ExtData via a build time option so that they can start preparing for it as I work on implementing new functionality desired which will only be in the new ExtData.
This adds "USE_EXTDATA2G" option to cmake so that if set to ON it will build MAPL with the new ExtData. Default is "OFF"

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Trivial change (affects only documentation or cleanup)

Checklist:

• I have tested this change with a run of GEOSgcm (if non-trivial)
• I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
• I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

[tclune]

My only substantive concern is whether there should be a run-time switch.

[bena-nasa]

I've added this

[mathomp4]

Interesting. We are now failing in the UFS build style. This build uses:

-DBUILD_WITH_FLAP=OFF -DBUILD_WITH_PFLOGGER=OFF -DBUILD_SHARED_MAPL=OFF

and this is somehow triggering on:

use yafyaml

@bena-nasa My guess is this line:

MAPL/gridcomps/ExtData2G/CMakeLists.txt

Line 27 in a922047

target_link_libraries (${this} PUBLIC GFTL::gftl GFTL_SHARED::gftl-shared esmf NetCDF::NetCDF_Fortran

needs an explicit YAFYAML::yafyaml (I suppose after the gftl bits so we keep GFE near GFE?).

It's probably currently getting yaFyaml through pFlogger via one of the other MAPL dependencies when we build with pFlogger. But without pFlogger, it needs an explicit dependence.