Add NavigableHakunaGeometry, a random access geometry view

[jampukka]

NavigableHakunaGeometry acts as a pull model for the HakunaGeometry in a backwards compat way. WKBBacked extends this even further allowing also write access to the backing coordinates for geometries that are stored in memory as ~WKB (for example geometries fetched from postgis and gpkg sources). This PR adds the framework + modifies EWKBTransformer to work with WKBBacked directly accessing the backing bytes for performant and low GC transforms.

Key classes:

• NavigableHakunaGeometry
  • Pull model: parts, then rings, then bulk copyRingXY per ring. Consumers that walk coordinates can use this instead of the push-model GeometryWriter.
  • HakunaGeometry#toNavigable() defaults to materialising JTS, so every geometry has a slow path and existing implementations keep working.
• WKBBacked
  • A HakunaGeometry whose coordinates already sit as WKB bytes in a buffer. Exposes the buffer, body offset, type and dimension, and setSrid.
  • Implemented by HakunaGeometryEWKB (postgis) and HakunaGeometryGPKG (gpkg)
• NavigableEWKB
  • The NavigableHakunaGeometry wrapping a WKBBacked. Scans the body once and records each part's byte order and each ring's offset and count, since every MULTI* member restates its own byte order.
• EWKBTransformer
  • transform(WKBBacked) reprojects the 2D coordinates in place, one transformInPlace per ring, with no JTS tree built and discarded.
  • The geometry reads back in the target coordinates and target SRID afterwards (setSrid also rewrites the SRID bytes of the EWKB or GeoPackage header; an EWKB without an SRID flag has no slot, so only the field changes).
• HakunaPropertyGeometry
  • 2D WKBBacked values go through EWKBTransformer, Z/M keeps the JTS path. The dimension is read from each geometry's WKB, not from the column's declared dimension.

Behaviour:

• A GEOMETRYCOLLECTION is not walked in place yet (matching existing HakunaGeometryGPKG code), so it keeps the JTS route when reprojected.
• EWKBTransformer.transformEWKB takes the byte order of each MULTI* member from the member's own header; before, a big-endian member after a little-endian one was read as little-endian.
• HakunaGeometryGPKG reads through its buffer instead of bb.array(). Not a bug fix: nothing on this branch hands it a direct buffer yet.