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

[ctrueden]

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.

[ctrueden]

I feel dumb for not grokking this before, but @hanslovsky already implemented this years ago with imglib/imglyb#7. The use case was Dask. So all we need to do to resolve this issue is add tests, either here or in imglyb or both...