Feature Request: ST_AsEWKB() and ST_AsEWKT()

## Summary

The DuckDB Spatial extension currently supports ST_AsText() (WKT) and ST_AsWKB() (WKB), but lacks support for Extended WKT (EWKT) and Extended WKB (EWKB) — formats which preserve essential metadata like SRID and are required for full standards-compliant geometry exchange with spatial databases like PostGIS, SpatiaLite, and others.

This feature request proposes implementing native support for:
- ST_AsEWKT(geometry) → returns a string with full EWKT (including SRID)
- ST_AsEWKB(geometry) → returns a BLOB/BYTEA with full EWKB (including endian flag and SRID)

## Motivation

DuckDB is increasingly used as an ETL engine, and the DuckDB Spatial extension makes it attractive for loading and transforming geospatial data. However, there is currently no safe or standards-compliant way to transfer geometries — especially those with an SRID — into systems like PostGIS without fragile workarounds.

Current limitations:

- ST_AsText() drops SRID and produces WKT only — incompatible with EWKT-consuming systems.
- ST_AsWKB() similarly drops SRID, producing WKB that can be misinterpreted by consumers expecting EWKB.
- Direct inserts into PostGIS via ATTACH postgres can fail with endian errors (Invalid endian flag value encountered) due to platform-specific binary serialization.

This leads to fragile and verbose pipelines where the user must:

- Manually append SRID as a string (for WKT)
- Create staging tables with BYTEA columns
- Reapply SRID using ST_SetSRID(ST_GeomFromWKB(...)) inside PostGIS

All of this could be avoided by simply producing EWKT or EWKB, which are:

- Explicitly designed for inter-system geometry exchange
- Understood by PostGIS, SpatiaLite, Oracle Spatial, GeoServer, GDAL/OGR, and more
- Cross-platform safe, due to explicit byte-ordering and metadata inclusion

## Proposal

Implement two additional spatial functions:

ST_AsEWKT(geometry)
→ Returns EWKT string, e.g., 'SRID=4326;POINT(1 1)'

ST_AsEWKB(geometry)
→ Returns EWKB binary with endian flag, SRID, geometry type and coordinates

Both functions would match [the semantics of PostGIS’s equivalents and follow OGC standards](https://postgis.net/docs/using_postgis_dbmanagement.html#EWKB_EWKT).
Benefits

- Native, robust ETL support for PostGIS and other geospatial databases
- Avoids platform-specific endian issues with binary geometry transfer
- Enables safe use of ATTACH postgres for direct geometry inserts
- Eliminates need for staging logic, manual SRID reapplication, or text parsing hacks
- Brings DuckDB Spatial closer to full interoperability with modern GIS tooling

## Example Use Case

-- In DuckDB

INSERT INTO postgres_conn.public.spatial_table
SELECT ST_AsEWKB(geom), name, category
FROM ST_Read('data/source_layer.gdb');

-- In PostGIS (geom is a geometry column)
-- PostGIS natively parses the EWKB and applies SRID, no manual parsing needed

## Conclusion

Support for ST_AsEWKT() and ST_AsEWKB() would be a simple but powerful addition that enables DuckDB to be a truly standards-compliant spatial ETL engine. It would eliminate common pitfalls and open the door to seamless interoperation with a wide variety of geospatial systems — not just PostGIS.