This is a followup PR that builds on top of
#19848 (although orthogonal to
#20143). Please have a look at
#19136 for the context behind this
PR.

This PR enables support for "shredding" geometry columns in our storage
format by internally decomposing the geometries into multiple separate
column segments when all the rows within a row-group are of the same
geometry sub-type. For example, if a row group only contains `POINT`
(XY) geometries, the column segment for that row-group gets rewritten
and stored internally as `STRUCT(x DOUBLE, y DOUBLE)` instead of `BLOB`
when checkpointing. This encoding is similar to how [GeoArrow]() encodes
typed geometries.

The major benefit of "decomposing" or "shredding" geometries from blobs
into columnar lists and structs of doubles like this is at the
storage-level is that they compress _significantly_ better in the
decomposed form. By decomposing the geometries into column segment of
primitive types we automatically benefit from DuckDB's existing (and
future!) best-in-class adaptive compression algorithms for each type of
component. E.g. the coordinate vertices get ALP-compressed, and polygon
ring-offsets get RLE/delta/dictionary encoded automatically based on the
distribution of the data.

In my (limited) testing, a fully shredded column is about half the size
as the blob-equivalent, i.e. shredding results in a 2x compression
ratio. This means that you get much faster reads from disk, and will be
able to keep more data in memory (as we now also compress in-memory
segments).

There are currently two caveats: 
- We don't shred segments that contain `GEOMETRYCOLLECTION`s, as they
can be recursive and don't have a fixed layout.
- We only shred if the _entire_ row-group is of a single geometry
sub-type. So if you have 10000 points, insert a linestring and
checkpoint, the column segment will be reverted back to physical type
`BLOB`.
- We don't shred segments containing EMPTY geometries, either at the
root or in sub-geometries.

We may want to consider "partial" shredding in the future, where we keep
multiple shredded segments around. But Im not sure if the
performance/complexity hit would be worth it.

Despite those limitations, geometry shredding still opens up some
interesting future optimizations opportunities:

- Push down certain filters (like bounding-box-intersections) much
deeper into the storage as they are faster to evaluate on separate
coordinate-arrays axis-by-axis.
- Emit "shredded" geometries directly from storage when casting or
exporting to GeoArrow
- Or if the optimizer realizes that all function expressions that read
from a fully shredded column have overloads that take the shredded
representation instead (e.g. spatial's `POINT_2D`), replace all
functions (or insert casts where needed) and emit the shredded
representation from storage to "specialize" queries automatically.

As it stands, In the case where there is no shredding, there is no
additional storage overhead. In other words, a non-shredded geometry
column is serialized exactly the same way as it used to (before this PR
lands).

I've made some changes to how `ColumnData` is serialized though. There
is now an abstract `unique_ptr<ExtraPersistentColumnData>` in the
`PersistentColumnData` struct that separates out the extra info required
by the `VariantColumnData` and `GeoColumnData`. As they are the only two
column data types where the type/layout can differ between segments
within the same column, they need to store some information to
reconstruct the layout and can't just rely on the top-level column
logical type. In the case of the variant, this is the "shredded" type,
but since geometries have a fixed number of layouts, we only store the
geometry and vertex-sub type (enums) instead of the equivalent logical
type to save space. I expect that we may want to generalize this further
in the future if we start implementing shredding to other types as well
(e.g. strings/json).

This is a followup PR that builds on top of
duckdb#19848 (although orthogonal to
duckdb#20143). Please have a look at
duckdb#19136 for the context behind this
PR.

This PR enables support for "shredding" geometry columns in our storage
format by internally decomposing the geometries into multiple separate
column segments when all the rows within a row-group are of the same
geometry sub-type. For example, if a row group only contains `POINT`
(XY) geometries, the column segment for that row-group gets rewritten
and stored internally as `STRUCT(x DOUBLE, y DOUBLE)` instead of `BLOB`
when checkpointing. This encoding is similar to how [GeoArrow]() encodes
typed geometries.

The major benefit of "decomposing" or "shredding" geometries from blobs
into columnar lists and structs of doubles like this is at the
storage-level is that they compress _significantly_ better in the
decomposed form. By decomposing the geometries into column segment of
primitive types we automatically benefit from DuckDB's existing (and
future!) best-in-class adaptive compression algorithms for each type of
component. E.g. the coordinate vertices get ALP-compressed, and polygon
ring-offsets get RLE/delta/dictionary encoded automatically based on the
distribution of the data.

In my (limited) testing, a fully shredded column is about half the size
as the blob-equivalent, i.e. shredding results in a 2x compression
ratio. This means that you get much faster reads from disk, and will be
able to keep more data in memory (as we now also compress in-memory
segments).

There are currently two caveats: 
- We don't shred segments that contain `GEOMETRYCOLLECTION`s, as they
can be recursive and don't have a fixed layout.
- We only shred if the _entire_ row-group is of a single geometry
sub-type. So if you have 10000 points, insert a linestring and
checkpoint, the column segment will be reverted back to physical type
`BLOB`.
- We don't shred segments containing EMPTY geometries, either at the
root or in sub-geometries.

We may want to consider "partial" shredding in the future, where we keep
multiple shredded segments around. But Im not sure if the
performance/complexity hit would be worth it.

Despite those limitations, geometry shredding still opens up some
interesting future optimizations opportunities:

- Push down certain filters (like bounding-box-intersections) much
deeper into the storage as they are faster to evaluate on separate
coordinate-arrays axis-by-axis.
- Emit "shredded" geometries directly from storage when casting or
exporting to GeoArrow
- Or if the optimizer realizes that all function expressions that read
from a fully shredded column have overloads that take the shredded
representation instead (e.g. spatial's `POINT_2D`), replace all
functions (or insert casts where needed) and emit the shredded
representation from storage to "specialize" queries automatically.

As it stands, In the case where there is no shredding, there is no
additional storage overhead. In other words, a non-shredded geometry
column is serialized exactly the same way as it used to (before this PR
lands).

I've made some changes to how `ColumnData` is serialized though. There
is now an abstract `unique_ptr<ExtraPersistentColumnData>` in the
`PersistentColumnData` struct that separates out the extra info required
by the `VariantColumnData` and `GeoColumnData`. As they are the only two
column data types where the type/layout can differ between segments
within the same column, they need to store some information to
reconstruct the layout and can't just rely on the top-level column
logical type. In the case of the variant, this is the "shredded" type,
but since geometries have a fixed number of layouts, we only store the
geometry and vertex-sub type (enums) instead of the equivalent logical
type to save space. I expect that we may want to generalize this further
in the future if we start implementing shredding to other types as well
(e.g. strings/json).

…20721)

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.

`GEOMETRY` Rework: Part 5 - Coordinate Reference System Support (duckdb/duckdb#20143)
feat(adbc): support `ADBC_INFO_DRIVER_ADBC_VERSION` (new in ADBC 1.1.0) (duckdb/duckdb#20344)
feat(adbc): support the uri option of ADBC 1.1.0 (duckdb/duckdb#20312)

`GEOMETRY` Rework: Part 5 - Coordinate Reference System Support (duckdb/duckdb#20143)
feat(adbc): support `ADBC_INFO_DRIVER_ADBC_VERSION` (new in ADBC 1.1.0) (duckdb/duckdb#20344)
feat(adbc): support the uri option of ADBC 1.1.0 (duckdb/duckdb#20312)

Co-authored-by: krlmlr <krlmlr@users.noreply.github.com>