refactor: define codec and data type classes upstream in a subpackage

[d-v-b]

Projects that want to implement their own codecs or data types have to import base classes from zarr-python. This means zarr-python can practically never depend on any externally-defined codecs or data types without creating a circular dependency (unacceptable). See #3867.

To remedy this situation, this PR defines our codec and data type ABCs in a separate package called zarr-interfaces. zarr-interfaces is a sub-package in this repo. The interfaces in zarr-interfaces are in versioned namespaces, which makes evolution of these APIs straightforward. Projects that want to implement a zarr-compatible codec or data type should depend on zarr-interfaces instead of depending on zarr-python itself. This will allow zarr-python to optionally depend on externally-defined codecs and data types.

I'm opening this as a draft because I'm not sure about quite a few things, and I would appreciate feedback on the basic direction.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/user-guide/*.md
• Changes documented as a new file in changes/
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

@zarr-developers/python-core-devs does anyone object to the basic proposal here: to upstream our basic codec + data type APIs? I think the current situation is untenable so I'd like to see it fixed. This PR is one approach, but I'm open to alternatives.

[normanrz]

I wonder if the versioning will create confusion, because it is another version apart from the zarr package and the zarr data format versions.

[d-v-b]

I hope it's not confusing! the goal here is to allow zarr-python to gracefully evolve things like the codec API. Since different codec APIs would not interact, we could define the current ABC-based API under v1, and a newer protocol-based API under v2. I think only codec and data type developers would need to know about this, and I would count on that crowd being able to know what the versions mean.