Thrown errors when processing "Next Feature" / ">" in multi-extent query on CBMTILE layer

[prushforth]

Steps to reproduce

Start a local instance of GeoServer on port 8084 (or adjust port number as required)
Set WMS MapML setting to serialize layers as multiple extents
Load this layer
Open the devTools console drawer
Zoom in on the spearfish sub-layer:

Click on a bunch of features in the spearfish extent
In the popup navigation footer, click "Next Feature / '>' "
What happens: StackOverFlow
What should happen: the next feature in the set of returned features' should be popped up.

[prushforth]

Have done a bit of debugging, and I think the problem lies in the fact that the first feature added to the shadow root of the <map-link rel="query" tref="...spearfish..."> via the "> Next Feature" button gets an incorrect fallbackCS from its _getFallbackCS(), which returns the default "gcrs" where it should be returning "pcrs" because no <map-meta> elements yet exist in the <map-link>.shadowRoot . Will investigate further as time permits. The error is not thrown when the projection is OSMTILE, but the problem still exists because the viewer thinks that the cs of the feature is gcrs, so in the above link the only expression of the bug is that the "Zoom to here" link goes off into some space uninhabited by people. ;-). Here's a link with the same layers in CBMTILE that throws the exception.

I think that two things need to be done:

1. make it so that if the query response returns <map-meta> they are guaranteed to be added to the <map-link>.shadowRoot first thing and
2. <map-feature>.getFallbackCS() should be amended to look a little harder for a projection and cs before actually falling back. i.e. for a <map-link> in a <map-extent>, it should be easily possible to obtain the projection from the <map-extent projection="..."> attribute, and the cs value should come from the first <map-input name="foo" type="location" units="..."> units attribute that is linked/related to the <map-link tref=...{foo}...> tref via the variable name.

[prushforth]

Not that this bug is due to lack of a spec for default cs value, but I noticed that the code ultimately does fall back to gcrs if there is no cs attribute on the geometry and no <map-meta name="cs"...> in the provenance of a <map-feature>, so I added it as something to specify