chore: Handle unsupported geometries (e.g. point empty) in GeoExecutor

[petern48]

In multiple PRs implementing geo kernels (e.g. 1 and 2), we've run across the item_to_geometry() lack of support for certain geometries like point empty. The root of the problem is that geo's methods simply return None for many of those cases.

In #233 (comment), @paleolimbot proposed creating a new enum to allow the caller to access the WKB directly.

enum ItemToGeometryResult { Unsupported(Wkb), Supported(Geometry))

I thought about taking this one step further, what if we instead do something like this:

enum ItemToGeometryResult {
    PointEmpty,
    MultiPointEmpty,  // we'd have to be extra careful here for cases like `MULTIPOINT (EMPTY, 1 0)`
    Supported(Geometry),
    Unsupported(Wkb),  // or just continue allowing these cases to panic since these are complicated cases anyway
}

This would allow us to avoid re-parsing the Unsupported geom's bytes again to determine that it's an empty point/polygon. This should work because we know what method is returning the None inside of the following function

sedona-db/rust/sedona-geo/src/to_geo.rs

Lines 76 to 87 in e0e1d10

	fn to_geometry(item: impl GeometryTrait<T = f64>) -> Option<Geometry> {
	match item.as_type() {
	Point(geom) => geom.try_to_point().map(Geometry::Point),
	LineString(geom) => Some(Geometry::LineString(geom.to_line_string())),
	Polygon(geom) => Some(Geometry::Polygon(geom.to_polygon())),
	MultiPoint(geom) => geom.try_to_multi_point().map(Geometry::MultiPoint),
	MultiLineString(geom) => Some(Geometry::MultiLineString(geom.to_multi_line_string())),
	MultiPolygon(geom) => Some(Geometry::MultiPolygon(geom.to_multi_polygon())),
	GeometryCollection(geom) => geometry_collection_to_geometry(geom),
	_ => None,
	}
	}

[paleolimbot]

That definitely seems like an improvement over the workarounds we have now...the "empty point within a collection" corner case is pretty rare in the real world and I think it's OK to not support it and see if anybody ever asks.

The system that @Kontinuation devised (geo-generic-alg) for rewriting algorithms to support geo-traits is probably what we should actually lean into if we seriously use more geo algorithms because it's much faster for most things (no copies). Because it's using geo-traits and is sort of a fork of the original can fix the behaviour to match PostGIS (even for the weird empties).