Enable correction for chromatic shifts

[jluethi]

Discussion started in #39

I do think correcting chromatic shifts is more of a niche topic though than general registration. The architecture should be able to handle this with similar workflows as image-based registration (i.e. shrinking ROIs to the consensus region while having 0s outside of it). Let's discuss here how we would compute such chromatic shifts.

High-level, I think this is an interesting category of tasks to figure out how we handle them. It probably is a bit too complex to fit into the napari workflows scheme (see here: #31). Because ROIs are shifted and existing images are edited (instead of new ones added), it wouldn't be the standard type of output. As such, it probably is a part of the registration tasks we build.

But the napari workflows are the only type of tasks where we support passing information in memory between steps (because Fractal considers the whole workflow to be a single task). Given that we will need to apply a small transformation to the images here and that's also what we need to do in the registration tasks, it is tempting to consider having chromatic shifts as part of a segmentation task.

Pro: Less IO, because we only shift each channel once, only write the change to disk once.
Cons: Task complexity and potential confusion. What if someone doesn't want to correct chromatic shifts? Or if someone invents a new type of chromatic aberration (i.e. not just pixel shifts, but more complex transformations) => would be useful to have this be independent of the registration task. Plus, we will have different types of registration tasks (e.g. 2D registration that could be very simple in scikit-image as well as complex 3D registrations through elastix) and we don't want to maintain the chromatic aberration correction in different tasks (that could use different libraries to do the actual image transformation)

=> I would tend to implement chromatic shift corrections as a separate task that has the IO overhead of having to read & modify the files again to avoid the complexity. If this actually becomes a limiting step, we can still build a more complex task that combines them were needed later, but the separate task should be the core implementation that's available.