Eave Mesh Generation - PoC to Main

### Are there any linked Issues or Pull Requests?

_No response_

### Brief description

Proof of Concept (PoC) branch for generation of eave-meshes which support existing science/ancil tools to work with cubed-sphere mesh topologies to be reworked for committing to main.

While science/ancils have found the output from the PoC branch acceptable, the implementation needs to discussed so its acceptable within a OO framework.

### Further details of the issue.

_C24 Cubedsphere with Panel-5 (top-panel) Eave-Mesh (eave_depth of 3-cells) overlayed_

An eave-mesh is named more as a result of it's usage _i.e._ it's association with a Cubed-Sphere mesh and how it is mapped. though it's topology is closer to a specific configuration of the `planar_mesh_type` with some extra info/methods relating to the eaves and associated cubedsphere panel. Each eave-mesh is:
* A grid of equal numbers of cells on each edge of the domain. ( of side Cubed-sphere number of panel edge cells + 2xEave_depth, _e.g._ 30 in the above diagram.
* Geometry=spherical
* Topology=non-periodic
* Coord-system=lon-lat
* Single 1:1 InterGridMap to the associated CudedSphere panel, where the Eave region is set to the `void id` to indicate there are are no mapped cells there.
* Node coordinate distribution/Mesh element id numberings differ from the planar mesh generator. They are treated in the same manner as the for CubedSphere panel-0
* Eave-mesh connectivity is oriented depending on the associated Cubed-sphere Panel number.

I'd suggest that:
* There is a eave mesh generation strategy object.
* The eave mesh generation object produces eave-meshes which are an extension of the `planar_mesh_type`, however in infrastructure the is 'planar_mesh_type' all meshes are classed as `global mesh type` which should probably be made into a class hierarchy.