GeoParquet support for shapes; refactor format

[LucaMarconato]

This PR introduces the use of GeoParquet to save shapes and replaces the old ragged array-based storage.

I also fixes the issue that only the geometry column was saved, now all the columns of the dataframe are saved.
Closes#311

Notes:

• No performance change is observed for writing (they are both binary formats). But GeoParquet improves interoperability.
• The PR is backward compatible: all previous datasets can be read, and the user can choose if writing the shapes with the latest format or with a previous format. This choice can be performed per-element.
• Tests are added to ensure the compatibility between the shapes "v01" and "v02"

These last two points required a overhaul of format.py and related code, code that now is more capable and robust. A few notes on this:

• For raster types we didn't introduce a "spatialdata format" because we were optimistic that transformations etc would have landed in NGFF faster; since they are not there yet, I believe that we need versioning also for raster types (which I now implemented).
• To avoid confusion between the version property, that always gives 0.4 and the spatialdata version, I renamed the version property to spatialdata_format_version. When writing points, shapes and tables, we need just the second one (because NGFF doesn't support them); instead, while writing labels and images we need both: ome-zarr-py needs to know that we are working with 0.4, and spatialdata needs to know which spatial data format for raster we are using to augment the NGFF storage.
• I have introduced a function _parse_version() that retrieves the spatialdata zarr version for a given element from its Zarr store.
• The function _parse_version() less clean that I hoped, this because of the versioning was done in a heterogenous way for the elements:
  • Shapes and points saved and still save the version under .attrs['spatialdata_attrs']['version']
  • Tables saved the version under .attrs['version'], they still save the version there for backward compatibility even if switching to .attrs['spatialdata_attrs']['version'] would be cleaner.
  • Images and labels didn't save the version at all, now they save it under .attrs['spatialdata_attrs']['version']. If _parse_version() can't find the version for raster types, it is assumed that the spatialdata RasterFormatV01 is used.

[LucaMarconato]

Ready for review, thanks 😊

[codecov]

Codecov Report

Attention: Patch coverage is 89.34010% with 21 lines in your changes missing coverage. Please review.

Project coverage is 89.94%. Comparing base (6d8aeb8) to head (32c65af).
Report is 41 commits behind head on main.

Files with missing lines	Patch %	Lines
src/spatialdata/_io/format.py	80.59%	13 Missing ⚠️
src/spatialdata/_io/io_shapes.py	92.30%	3 Missing ⚠️
src/spatialdata/_io/io_table.py	90.62%	3 Missing ⚠️
src/spatialdata/_core/spatialdata.py	88.88%	1 Missing ⚠️
src/spatialdata/_io/io_zarr.py	75.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #542 +/- ##
==========================================
- Coverage 90.04% 89.94% -0.10% 
==========================================
Files 44 44 Lines 6670 6755 +85 ==========================================
+ Hits 6006 6076 +70 - Misses 664 679 +15 

Files with missing lines	Coverage Δ
src/spatialdata/_io/__init__.py	100.00% <100.00%> (ø)
src/spatialdata/_io/_utils.py	87.07% <100.00%> (+0.18%)	⬆️
src/spatialdata/_io/io_points.py	100.00% <100.00%> (ø)
src/spatialdata/_io/io_raster.py	96.00% <100.00%> (+0.34%)	⬆️
src/spatialdata/models/models.py	87.66% <100.00%> (+0.05%)	⬆️
src/spatialdata/_core/spatialdata.py	90.89% <88.88%> (-0.09%)	⬇️
src/spatialdata/_io/io_zarr.py	88.50% <75.00%> (+0.13%)	⬆️
src/spatialdata/_io/io_shapes.py	95.23% <92.30%> (-2.73%)	⬇️
src/spatialdata/_io/io_table.py	93.87% <90.62%> (-6.13%)	⬇️
src/spatialdata/_io/format.py	84.35% <80.59%> (-5.12%)	⬇️

[LucaMarconato]

Todo:

• update changelog

[LucaMarconato]

The docs started failing in a different PR, I'd address that separately.

[giovp]

looks great! Much needed update, small comments

[LucaMarconato]

As you prompted, I have updated the docs. Now the API page from the docs has this in the end (left panel in the figure).

Please noticed that the first class is non-clickable (pink). This because we define the SpatialDataFormat class simply as

classSpatialDataFormat(CurrentFormat):
pass

But if we had it to the docs, since we inherit from ome_zarr.format.CurrentFormat, the user would get this confusing page (right panel in the figure).

[LucaMarconato]

Ready to merge, I'll fix the (unrelated) problem with the docs in a new PR.