Integrate GEOS into GeoPolars under a optional feature-flag

[phayes]

A proposal to integrate GEOS into GeoPolars

1. Stick to WKB short term and move to GeoArrow when it's ready. No stored GEOS objects.
2. Talk to GeoArrow folks about "once in memory is cheap to convert to geospatial libraries (e.g. GEOS)" and implement whatever is needed to make this efficient transformation.
3. Always convert to and from GEOS for doing operations. Make this explicit in the documentation and always have GEOS flag turned off by default.
4. As we have time, replace GEOS functions with their rust equivalent.
5. Remove GEOS when all functions have been ported to pure-rust.

Open Questions:

1. Linking. It would be nice if we could statically link GEOS. But there are licensing issues to resolve on this.
   A. GEOS is LGPL-licensed
   B. https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

2. Thread safety. It would be nice to include rayon support, but may not be possible for GEOS geometries depending on if they are thread-safe or not.

[kylebarron]

Repeating somewhat from discord:

I originally didn't plan to use any GEOS because

• Adding GEOS as a dependency makes the code less portable
• Storing geometries in GEOS memory makes the memory less portable, as you're no longer zero-copy with the Arrow ecosystem
• Packaging GEOS might be hard for the Python bindings

1. Stick to WKB short term and move to GeoArrow when it's ready. No stored GEOS objects.

Storing geometries in Arrow vs GEOS memory is a tradeoff: if they're stored in Arrow memory then every GEOS operation needs to copy and convert from Arrow memory -> GEOS memory -> Arrow memory. If they're stored in GEOS memory, then the data is no longer zero copy to the Arrow ecosystem.

The goal of using pure rust algorithms is that in the future we'll be able to implement geometry access traits (see georust/geo#838 (comment)) so that geo algorithms can read from geoarrow memory directly. It's not clear it would be possible to retrofit GEOS to read from Arrow memory, and regardless that would need to happen in C I assume.

If we wanted to store geometries as GEOS objects, we should be able to use the polars object extension, which I think allows storing arbitrary rust structs.

Storing geometries as WKB is just a hack until we get an arrow-native implementation working. I'd like to switch geopolars to a geoarrow struct encoding somewhat soon, even if it's not zero-copy to geo yet. This geozero PR will help with that. An arrow encoding should be much faster than WKB.

2. Talk to GeoArrow folks about "once in memory is cheap to convert to geospatial libraries (e.g. GEOS)" and implement whatever is needed to make this efficient transformation.

It's true that geoarrow <--> geos is expected to be cheap, but not free. I expect that the overhead of copying to/from geos for every operation would not have ideal performance. But this would be good to prototype. See this PR for an example of work to convert data efficiently between GEOS and GeoArrow.

[kylebarron]

Initial scaffolding of GEOS support now exists here: https://github.com/geopolars/geopolars/tree/8cc532e72442eb6e396fa1d2076ecf9326efc738/geopolars/geopolars-geos