Improve OpSearchResult to give limited type information in stringified op

[ctrueden]

Right now, multiple op search results look identical, e.g. several math.add(arg, value) lines. We need to include some type information, but without overwhelming the user with too much detail.

See also imagej/napari-imagej#46.

[gselzer]

The important information we are missing is the typing. Outside of renaming image types to image, we are missing all typing information, which is leading to the duplicate ops that only differ on typing. I've been playing with some ideas that could introduce typing.

I want broad type renaming, because some of our types (looking at you, ImgLib2) are so long. I'm thinking something like numpy-esque dtype names, e.g. (UnsignedShortType -> uint16). This will also mesh better with image, and the numbers prevent conflicts with the primitives.

I've written a UnaryFunctionOp<Img<UnsignedByteType>, String>> named foo, bar with an UnsignedByteType parameter named value. It would currently appear as foo.bar(image, value).

What might we want that to look like?

• foo.bar(image<uint8>, value: uint8) -> String (python-esque syntax)
• String foo.bar(image<uint8>, uint8 value) (java-esque syntax)
• ...

My personal favorite (I like the arrow output syntax and the quotes around the name, drawing attention to the meaning of that word):

• foo.bar(image<uint8>, uint8 "value") -> String

[ctrueden]

See also https://github.com/imagej/napari-imagej/issues/56#issuecomment-1146189727