Usage of Slicewise (and others...)

Hi all,

while developing with `Op`s, I figured that it is _very_ annoying that I have to instantiate the `Op` I want to use in a `slicewise` before hands and then pass the `Op` again to the `slicewise`. This is not only annoying, but also we often get the wrong op.

Imagine there exists a `CrazyComputerOp` which has two implementations, one for 2D and one for 3D. My input image is 3D. However, for some reason, I want to process my 3D image `slicewise` on `X,Y`. The current way of first creating the `Op` and then passing it to `slicewise` can result in three different results:
- I pass the types of input/output when asking `Computers.unary(CrazyComputerOp.class)`
- I pass the actual object instances. `Computers.unary` however will then return an `Op` for `3D` which may not even work on the 2D images produces by `slicewise`.
- I'm smart and crop the input/output in the right way (as slicewise would do it) and pass this to `Computers.unary(...)`. Then I get the desired `Op` but have plenty of additionally code.

My ideas are as follows:
- In the namespace we could provide a method called `slicewise(OUT, IN, DROP, Op.class, OpArgs)` which will do the magic
- For every `ComputerOp` we force in the `Namespacetest` to provide an additional method with an `axes` parameter, which performs the slicewise.

I prefer the second idea, however I don't know how applicable this is. Because this pattern (creating an `Op` and passing it to another `Op`) seems to pop-up over and over again (e.g. `Map`). Any ideas?

Cheers,

Christian

Start by tracing the slicewise and Computers.unary usage described in the issue, then inspect the ComputerOp and Namespacetest APIs, including the related Map pattern. This needs a design decision for how slicewise should select or construct operations; done means an agreed approach is implemented consistently and its behavior is validated.

Written by the indexing model from the issue text.