Full support for dask arrays

[imagejan]

We should consider supporting DaskArray throughout the pipeline, in faim_hcs.io.* and in faim_hcs.Zarr.

For example, if the assemble_fn parameter for the get_well_image_C[Z]YX functions can be a Callable accepting dask arrays and returning a single (stacked/blocked) dask array, the function should not create a np.zeros() array first and fill it with the tile pixel data, but instead keep a list of arrays and use da.stack() with appropriate chunking options to create the CYX or CZYX output.

This would allow the pixel reading operation to be deferred until the writing step in Zarr.write_image_and_metadata.

[imagejan]

Related:

• metadata handling could (should?) be separated from the pixel data, as in some formats (e.g. CellVoyager) the metadata are already completely separate (.mlf etc.) from the pixel data (e.g. .tif without spatial calibration).
• a remaining question is how to deal with the histograms (UIntHistogram): should we still read all pixel values to create them immediately when processing/stacking the image, or rather delay creation until we actually write the well/field into the zarr store?

[tibuch]

Solved with #58 and #59.