Understand how CRS should be represented in UGrid

[hdyson]

This issue is not ready to pick up and implement - there's a reasonable amount of investigation still needed. When this does become an active issue, it will probably need significant coordination with the iris developers.

✨ Feature Request

It is not clear how a coordinate reference system (CRS) should be implemented for UGrid data. Consequently, it's not clear whether iris supports UGrid CRS definitions, or we need changes upstream. This ticket should cover that exploration.

Initially marked as low priority: we can assume spherical Earth for GC5-LFRic, but this will probably need a better resolution for RAL3-LFRic.

From Patrick Peglar (@pp-mo) on MOSRS:

In Iris at present, it is at least possible to attach a coord-system to coordinates of a mesh.
But these will not create a grid-mapping when saved out, and an unstructured Iris cube will never return the crs from its cube.coord_system(), since it has a mesh instead of X/Y-axis dim-coords.

However, it is at least possible to co-opt the Iris netcdf load/save code, in order to encode a crs as a grid-mapping in a file, and to extract it back out again.
Crudely that can be done by creating a small, independent variable, with a dimcoord containing the desired CRS.

Subsequent to that comment, a partial fix was added to iris: SciTools/iris#6016

Outstanding questions include:

1. How well defined is this problem in terms of UGrid and CF conventions?
2. Is the existing iris fix sufficient for our use case? This may include needing to implement some new functionality in UG-ANTS.
3. If not, can we provide clear requirements for refining it and feed these to the iris developers?