Support wrapping any arraylike object, which may not be a block of memory, to ImgLib2

Naively, this means writing a Python-side class that implements e.g. `Img` or `Dataset` or whatever interface, providing all the methods, but backed by the Python-side arraylike object. No memory shenanigans.

But the naive approach will be extremely slow for things like iteration of samples, because each sample access is across the JNI boundary. So then we have what @hanslovsky wrote in #73:

> I have wrapped a numpy-like object into a cached cell img. I don't remember what exactly the object was but as long as the individual cells can be mapped to native memory, this shouldn't be too much of a challenge. It is a different story for completely arbitrary objects, though.

Which could help with performance when we have raw memory access per cell.

Start by reading this issue alongside issue #73, which describes wrapping a numpy-like object as a cached cell image. Compare the proposed Python-side interface with the cached-cell approach and determine the supported arraylike scope. Done means defining and implementing a viable wrapping strategy, including an acceptable approach to sample-access performance.

Written by the indexing model from the issue text.