Support CRSs on other datums (NAD27, OSGB, CH1903+, ...) #243

Context

The projection-genericity effort (#237–#241) deliberately scoped all work to CRSs on the WGS84 datum. Every new projection (EPSG:3395, EPSG:32662, all 120 UTM zones) converts through the WGS84-based EPSG:4326 pivot, and Coordinate3D carries WGS84 ellipsoid constants only (GISTool.equatorialRadius, wgs84EccentricitySquared, ...).

Why datums are the hard remaining piece

Supporting e.g. EPSG:4267 (NAD27 geodetic) or EPSG:27700 (OSGB 1936) is not just adding another ProjectionDefinition two-step:

1. Different ellipsoids: definitions need per-ellipsoid parameters (Clarke 1866, Airy 1830, Bessel, ...), affecting every forward/inverse formula
2. Datum transformation: converting geographic coordinates between datums requires
   • 7-parameter Helmert transformations where reliable (with epoch + realization caveats), or
   • interpolated grid shifts (NADCON, NTv2) for accuracy — which means embedding/obtaining grid data
3. Semantics baked into the code: many algorithms assume "geographic == WGS84 degrees" (Haversine with GISTool.earthRadius, antimeridian handling, asJson → 4326 serialization per RFC 7946). A NAD27 kind == .geographic projection would flow through those paths with wrong constants

Suggested approach (when taken up)

1. First step: per-definition ellipsoid parameters (replacing the hard-coded WGS84 globals in definitions) — this alone enables fully WGS84-family extensions with 0 risk
2. Then: datum model (Datum metadata on definitions) + Helmert-based pivot for datum shifts between datums, keeping WGS84 as the only GeoJSON serialization space
3. Grid-shift support (NADCON/NTv2) only if sub-100 m accuracy is actually needed; Helmert'ed datum pairs are frequently off several meters for older frames

Scope anchors

• Phase planning split this out explicitly ("roughly doubles the effort")
• Public/custom-projection API issue: Public API for third-party / custom projections #242 — a public registration seam interacts with this (custom datums are the realistic user need)

Related

• PR chain: Introduce ProjectionKind and capability-based projection dispatch #237/Route projections through a ProjectionDefinition registry #238/Add EPSG:3395 and EPSG:32662 projections #239/Registry-driven WKT CRS matching and coder/tile test coverage #240/Add UTM zone projections (EPSG:32601–32660, 32701–32760) #241