This is a followup PR that builds on top of #20143, please have a look at #19136 for the context behind this PR.

This PR makes additional changes to how coordinate systems are handled for the GEOMETRY type.

Shrinking, Expansion, and Identification of coordinate systems

In the initial iteration of parameterizing geometry types with coordinate systems, we basically allowed any string to be stored as the CRS, and then tried to parse and identify the format (projjson, wkt2:2019, auth:code, srid) before extracting a "name" or "identifier" which we stored separately to use when printing the type.

This has the major downside that the textual representation of a geometry type (or SQL schema containing geometry types) no longer round-trips. I.e. if you parse it back, you no longer get the same type. This is primarily a problem when doing a EXPORT DATABASE, SUMMARIZE or calling .schema in the shell. However, the alternative of always printing the full definition is also... untenable as it makes the SQL extremely unfriendly to read.

The compromise implemented in this PR is to alway print what's actually stored in the type info, but also try to "shrink" the actual CRS definition to e.g. its auth:code when parsing a CRS, if the definition is a CRS that we recognize (and should therefore be able to "expand" into a full definition again later).

As an example:

• If we read a GeoParquet file, which has the default coordinate system "CRS84" in projjson format, we only store "OGC:CRS84" in the geometry type, because DuckDB knows how to convert "OGC:CRS84" back into the projjson (or WKT2) later if needed.
• But if we read a GeoParquet file with some other unrecognized CRS definition (e.g. "SOME_ORG:1337", but in projjson) we store the full projjson, and simply live with the fact that the type will be hideous to display.

We also by-default now throw an error if we try to create a geometry type with an incomplete unrecognized CRS. I.e. a auth:code or opaque identifier. We always allow PROJJSON or WKT2 definitions even if we don't recognize them, as they are complete in the sense that they can be interpreted on their own, but we don't shrink them if we don't know them. This handling of unrecognized coordinate system identifiers can be controlled with the ignore_unknown_crs setting.

This means that you can still just pass around complete projjson or wkt2 definitions and deal with the ugliness if you really want to use your own custom coordinate systems, but in practice 99.9% of coordinate systems will be recognized by spatial.

While you can't define your own "known" coordinate systems through SQL, you can do it through your own extension (or application that embeds DuckDB) by providing instances of the new CoordinateSystemCatalogEntry in the system catalog.

Coordinate System Catalog Entries

There is now a new type of catalog entry to store coordinate system definitions, the CoordinateSystemCatalogEntry. These can be registered by extensions to provide additional coordinate system definitions. For example, the spatial extension now registers its list of EPSG and OGC-defined coordinate systems by lazily pulling them from the embedded PROJ library.

But this PR also adds "OGC:CRS84" and "OGC:CRS83" definitions in core. This list of built-in definitions may or may not be extended in the future. Or we may create a separate dedicated extension that only supplies coordinate system definitions (similar to icu and encodings).

Support for CRS propagation through (Geo)Arrow import/export

This PR also adds support for propagating the CRS when exporting/importing from (Geo)Arrow. I had to make some changes to drill-down the client context into the arrow extension code, but we always have it available when resolving extension types anyway so the changes only really touch the internals.

A nice consequence of this is that spatial:s GDAL integration automatically handles CRS propagation now too as its based on arrow, meaning that ST_Read() outputs GEOMETRY columns with the CRS specified by the underlying file, and COPY ... TO (FORMAT GDAL) also encodes the CRS properly.

Update spatial to v1.5 Branch

This PR also adds back and bumps spatial to the v1.5 branch.