Fixes for dimension and tiling issues

[dgault]

This primarily addresses the issues with incorrect dimensions and incorrect tile size as reported in #17

Testing should be carried out on the datasets mentioned in the related Issue

Fixes #17

[sbesson]

Functionally this work e.g. the czy.ome.zarr dataset from https://github.com/ome/ome-ngff-prototypes#examples is now properly detected as multi-channel

and the tczyx.ome.zarr is 5D

Note on the latter the thumbnail is broken. This is not a limitation of the reader itself but of OMERO which does not support multi-resolution images with downsampling alongside Z (other pyramidal readers like BDVReader have the same issue).

The primary issue is that the dimension order detection is based on the _ARRAY_DIMENSIONS metada stored at the array level. After several rounds of discussions, this specification was removed from the 0.4 specification - see ome/ngff#96.
While these examples still include this metadata, I do not think the reader implementation should rely on them and use the axes metadata at the multiscales level as the single-source of truth for versions 0.3 and above (the dimensionality should be enforced as TCZYX for versions 0.1 and 0.2)

[sbesson]

Tested various samples for versions ranging between 0.1 and 0.4.

• all samples detect the correct tile size using the last 2 dimensions
• I found no unexpected/mismatching dimensions

For a few samples e.g. ome-ngff/0.3/idr/idr0095B/11511419.zarr or 0.3/idr/idr0052A/5514375.zarr/.zattrs, the reader created an invalid dimension order enum e.g.

ome.xml.model.enums.EnumerationException: 'XYZCTXYZCTXYZCT' not a supported value of 'class ome.xml.model.enums.DimensionOrder'

I would suggest we get the dimension order fixed and then this can get merged in order to review #24. Some of the sample files generate invalid OME-XML as well but I think some of the fixes in #23 are relevant. Once both sets of fixes are in, we can probably audit the reading of all samples.