Feat/multiscale tests

[d-v-b]

I bring in a lot of the tests and validation logic from pydantic-zarr.
A few notable changes I add here:

• I added .build methods to VectorScale and VectorTranslation that allow you to create the respective transform without explicitly passing in the type as a (redundant) keyword argument
• I added a private _build_transforms function that creates tuple[VectorScale] | tuple[VectorScale, VectorTranslation], this is a convenience function for making coordinateTransformations metadata.
• I add validation functions for transforms and axes, and the corresponding pydantic model type annotations

[d-v-b]

I added validation + tests to ensure that the number of multiscales.axes matches the dimensionality of the transforms defined in multiscales.coordinateTransformations (if present), and separate validation / tests to ensure that the axes match the number of transforms in the per-dataset coordinate transformations

[d-v-b]

i think this is ready for review!

[d-v-b]

this should resolve #33

[dstansby]

Shouldn't we keep this as >=3.11, as per SPEC 0?

[d-v-b]

ah right, this change needs to be reverted

[dstansby]

Could we instead give type a defualt (type: Literal["scale"] = "scale"), and then if you want to construct one of these you can just do VectorScale(scale=[1, 2, 3])? I think that's slightly nicer API and avoids us having to write a build method.

[d-v-b]

the argument against giving the type a default value was that this would allow a JSON object without a type field to pass validation, even though that JSON object is technically an invalid axis

[d-v-b]

(I totally agree that the API is nicer if the default is the de-facto default)

[dstansby]

In the spirit of don't repeat yourself, I'm not mad about having ndim defined as both a method on the classes and a function. Was there a particular reason for doing this?

[d-v-b]

the main reason to have a free-floating function is to support the niche case of using a functional idiom like map or filter on transformation objects, e.g. ndims = map(ndim, transforms), but maybe this is too niche :)

[dstansby]

Would be good to extract the type here as a type alias (or type var???) to avoid repetition.

TransformType = tuple[VectorScale | PathScale] | tuple[VectorScale | PathScale, VectorTranslation | PathTranslation]

[d-v-b]

definitely, we can define + export this union in the transformations module

[dstansby]

Having read this function, to simplify it I would actually decouple the validation from the spec a bit, and write the validation function to check that an arbitrary list of transforms (that therefore have a .ndim attribute) have the same number of dimensions.

So:

1. Remove all transforms from the list that are Path transforms
2. If >= 2 transforms left, check they have same dimensions

I think this will make typing/logic a bit nicer, and also make this a bit more re-usable for whatever comes in coordinate transform changes.

[d-v-b]

good idea! I will implement this

[dstansby]

How is this meant to be used? I am a bit confused/not understanding what the purpose of this class is.

[d-v-b]

this class will model an actual zarr group, i.e. the attributes (which are JSON and ought to contain multiscales etc) and the arrays (which ought to be the ones named by the path attribute in datasets, and which ought to have shape that's consistent with the number of axes, etc)

[d-v-b]

this class is also the thing we deserialize a zarr group into