Support for private remote object storage

Right now, there is support for local .zarr stores and remote stores publically accessible via HTTP or S3.
Private remote stores are more difficult, as they need certain options or credentials that are not representable by simply a string or Path. One option is to use a zarr.storage.FSStore, which can have storage_options or any fsspec.spec.AbstractFileSystem.

Two pull requests enable this:

• Support init of ome_zarr_py.io.ZarrLocation with zarr.storage.FSStore (#349)
• Support remote private storage by consistent use of substore (#442)

Testing is difficult, but this is what I used:

import spatialdata as sd
import zarr
# works now, requires credentials in ~/.aws/credentials
root = zarr.open('s3://BUCKET/spatial-sandbox/visium_associated_xenium_io.zarr', storage_options = {'client_kwargs': {'endpoint_url': MINIO_URL}})
sd.read_zarr(root)
# still works, I think depends on zmetadata?
sd.read_zarr('https://s3.embl.de/spatialdata/spatialdata-sandbox/visium_associated_xenium_io.zarr/')
# still works
sd.read_zarr('~/visium_associated_xenium_io.zarr')

Start by reading PRs #349 and #442, which the issue identifies as enabling support for private remote storage. Reproduce the shown zarr and spatialdata examples with credentials and storage options; done means private remote stores work while the existing HTTP and local store examples continue to work.