Create pygeoarrow and use it for cuSpatial feature storage and i/o

[thomcom]

This closes #582.
This PR removes the input based on an iterative Shapely reader and cudf buffers. Now the input is stored directly in a pyarrow UnionArray. The next PR will remove most of the interior functionality that is not necessary.

[thomcom]

The next PR will have tons more - than + I think.

[thomcom]

This PR is messy because the old wrapper and pyarrow are co-existing.

[isVoid]

Since this is my first review of geoarrow PRs, so bear with me if I have missed some background knowledge. I have a high level question for GeoColumn. Why is GeoColumn a NumericalColumn? It seems to me no single existing cudf column type is sufficient to represent what GeoColumn expresses. It seems a bit awkward to piggy back on existing methods defined for NumericalColumn.

However, each "pure geometry" arrays can be represented as a ListColumn in cuDF. My intuition is that we can use ListColumn for each of the pure geometry arrays. The indexing logic introduced here for GeoColumn can continue serve as the top level indexing (similar to UnionArray indexing).

[thomcom]

Thanks for your comments! I'll cover each and hopefully we can merge this. This is a partial contribution, and many of your concerns will disappear in the next two.

GeoColumn was a NumericalColumn because it enables it to be used with existing cudf algorithms that focus on the other dtypes. For example, one can call groupby on a GeoDataframe on a non-geometry column, which will then produce meaningful results. See test/test_geodataframe.py for a simple example. I assume that this will work even better when the type is updated to a ListColumn.

Thanks for the reminder, I'll be sure to create an issue for Refactor from NumericalColumn to ListColumn.

[isVoid]

Awesome, as requested I only went pretty broad-strokes this time and I see no red flags. I see there are internal calls to assert_eqs that can hopefully be replaced in future PRs.

And just to be clear, groupby is only promised at a indexed_frame level in cudf and is very much a separate implementation unrelated to column. see:
https://github.com/rapidsai/cudf/blob/branch-22.08/python/cudf/cudf/core/groupby/groupby.py

It totally makes sense to implement geoseries and geodataframe inheriting from series and dataframe to make use of the compute APIs for non-geometric columns. But geocolumn is too eccentric that I think it's best to implement an underlying UnionColumn type in cuspatial and geocolumn can inherit from it.

[thomcom]

@gpucibot merge