EPIC: Refactor table readers and 3D array support

[kylebarron]

I would like to use (or at least have the option to use) geoarrow-rs in contexts like Lonboard. But 3d data is common enough that I need to be able to handle it. I think the best way to start 3D support is potentially to support them

The order listed here is not necessarily the best order of work.

• Set up Rust monorepo with multiple crates
• Create geoarrow-io crate. Move existing IO functionality into that crate. This should vastly simplify the dependencies in the main geoarrow crate.
• Refactor type signatures of readers and writers. The goal here is to decouple the readers from the GeoTable concept. It should also improve functionality with streaming operations and support future integration with Datafusion.
  • Implement conversion from a RecordBatchReader to a GeoTable. #595
  • Sync readers should return a RecordBatchReader #596
  • P1 Python APIs to sync readers should return a RecordBatchReader object
  • P2 Async readers should return a RecordBatchStream? Note that this means the geoarrow-io will have to depend on datafusion...
  • P0 Sync writers should accept a RecordBatchReader.
  • P1 Async writers should accept a RecordBatchStream?
• Extend array builders to support 3d coords
  • Most array builders work in terms of geo traits, so we'll need to first support additional dimensions in the traits.
  • Extend array types to have a const generic parameter
  • ...
• Refactor writers to accept a RecordBatchReader.
• Refactor GeoTable to Table, remove a hard-coded geometry column index. Note that this is not necessary for the initial parsing as long as you're able to convert the RecordBatchReader into a GeoTable.

[kylebarron]

Python geoarrow-rust-io submodule