ND data loading with other axis orders

[fm3]

• enables ND data loading for all data formats with AxiOrder and AdditionalCoordinates (precomputed, n5, zarr3) (previously only zarr2)
• volume annotation data.zips should now be viewable as datasets after unpacking (fixed the indices of their additional coordinates)
• unifies DatasetArrayHandle (previously CubeHandle, no longer a trait with multiple implementations)
• no more distinction between reading with or without AdditionalCoordinates from DatasetArray
• Added some more tryos for better error handling
• FullAxisOrder is now constructed for reading with arbitrary ND axis orders, with permutations from array order to wk order (tcxyz), including one for flipping c to fortran in the process
• Adds some tests for these permutatinos

Steps to test:

• Unpack zarr volume download data zip (both 3d and 4d), should be viewable as dataset
• View 4d and 3d and 2d zarr datasets, should be viewable

TODOs:

• fix volume annotation metadata (additional axes have wrong indices)
• fix permute (needs to take additional axes into account)
• test with volume annotations
• test with 2d zarr
• add tests for the permutations in c and f
• fix viewing nd datasets without the additional coordinates in the json (cxyz should still be accessible if normal axisOrder field is correct)

Issues:

• fixes #7280

---

• Updated changelog
• Needs datastore update after deployment

[frcroth]

Very good job!

[frcroth]

Suggested change

	chunkIndex <- chunkIndices.headOption.toFox
	chunkIndexInWk <- chunkIndices.headOption.toFox

?

[fm3]

I’m hesitant, because then we would have to annotate shape, offset, chunkIndices, sourceChunk as well. It’s true that this ordering is important to understanding this function, but it is not the only thing going on here, so I’m scared the renamings would generate too much noise. Instead, I tried to make the comment more descriptive. What do you think?

[frcroth]

I'm fine, either way this PR should be an improvement.