Virtual concatenation of arrays with different codecs or dtypes

[TomNicholas]

The motivation for this is in zarr-developers/zarr-specs#288. A VirtualZarrArray class can be prototyped in this library, but can't be serialized in a way that can be read by any Zarr readers until that upstream work is done.

Eventually we probably want to change the default concatenation behaviour to concatenate using VirtualZarrArrays instead of ManifestArrays.

[TomNicholas]

Currently np.concat called on two ManifestArray objects with different codecs will raise an error here:

https://github.com/TomNicholas/VirtualiZarr/blob/f226093bcb8ad248b7a2c8cdcadd224747089792/virtualizarr/manifests/array_api.py#L54

[TomNicholas]

Virtual concatenation would also allow for concatenation of arrays with different dtypes, see #215 for an example.

[TomNicholas]

Note the proposed approach in zarr-developers/zarr-python#2536

[TomNicholas]

There's an important potential use case for chunk-dependent codecs: storing LLM model weights in Zarr. Those often have "quantization" (basically bit packing, or scale and offset-like encoding), but sometimes it's on a per-chunk basis.