Kyle Barron

Started in #138; it's just a bit more copy-pasting to get it working for all the algorithms where the right hand side can be a scalar

Note: this is being switched to favor blanket implementations on geometry traits

I don't want to implement traits on both scalar types because of so much code duplication. Hopefully with blanket implementations on geometry traits it should be less code.

In https://github.com/geoarrow/geoarrow-rs/pull/288 it was changed to be implemented on a slice but not vec. it would still be nice to get this implemented on `AsRef`, but I had issues getting...

I hit issues recently where I couldn't implement this both on `[G]` and `[Option]` because the upstream G implementation could in the future add an impl on `Option`. Still not...

Can you give some context about why we should do this? Presumably this is to simplify version resolving when a third party user is also using these crates, but a...

I'd prefer to not re-export for now. It's easier to add this in the future than to take it away.

In the short term, until georust adopts traits for its algorithms, this would need a conversion from `PointTrait` to `geo::Point`, and from `LineStringTrait` to `geo::LineString`, so that the implementation could...

For now, just move `slice`, `with_coords`, `into_coord_type` and `owned_slice` to another trait, to make `GeometryArrayTrait` object safe

Yes and no, the first trait should exist but not be required by `GeometryArrayTrait`.