support transposition of acquisition dimensions -> (different) storage dimension

[tlambert03]

This PR is my attempt (with the help of claude, and generous comments from @marktsuchida) to fix #171

This adds a new storage_dimension_order attribute/parameter to ArraySettings, with the following docstring:

  storage_dimension_order: Order of dimensions for storage, which may different
    from the acquisition order defined in `dimensions`. Must be a list of dimension
    names corresponding to those in `dimensions`.
    This allows reordering according to the desired final layout (e.g.,
    `[TIME, CHANNEL, Z, Y, X]`, which is currently mandated by the OME-Zarr
    specification).
    Notes:
        - The first dimension *may not* be moved to a non-leading position.
        - The last two dimensions *may not* be moved out of the final two positions,
          but MAY be swapped with each other.

• Note, the two restrictions on transposition of the first and last two dimensions came after finding some deeper hard-coded assumptions in the code base, so these are just "not implemented" errors for now, to avoid accidents.
• I'm not 100% certain about the impacts of transposing adjacent chunked dimensions (e.g. TC[ZYX]) to non adjacent positions: T[Z]C[YX] ... so would appreciate your input here.
• i did include support for transposing the last two dims YX -> XY ... but can definitely remove that bit if you want to consider it independently (we would just raise not supported on any transposition involving the last two dims)
• This is designed to be opt-in, so no one should notice any change (performance or otherwise) without passing in a storage_dimension_order target.

---

random other thoughts:

• i'm still not entirely sure I "care" that we're writing data that is not compliant with the "order of dimensions" norm in the ome-zarr spec. I think I disagree pretty strongly with the clause in the spec that states dimensions MUST be ordere TCZYX. However, since what I ultimately want is to write out a file that end-users can take with them to other programs (fiji, vizarr, napari, etc...) i'm inclined to just do what they say... hence this PR

[tlambert03]

tests failing because zarr directly imports a transitive dependency pulled in from numcodecs without adding it to dependencies ... and numcodecs removed it : zarr-developers/zarr-python#3592