Consider a simpler syntactic variant for writing ops

First, there were commands. They have fields with `@Parameter` annotation noting that the field is considered a parameter (either input, output or both) to the command.

Then we built ops on top of commands. They also use `@Parameter` annotations on fields.

Then we added type-safe method signatures for all the ops available in the core library. And put in a lot of effort to ensure the type-safe methods stay "in sync" with the op implementations themselves.

But duplicate data structures are bad. Is there any way we can combine things, such that the op declares the type safe method somewhere, which _is_ the op implementation?

For example:

``` java
@Plugin(type = OpNamespace.class)
public class CoolNamespace extends AbstractNamespace {

public > T awesome(
@Output final T outImg,
final T inImg,
@Optional final Boolean beExtraAwesome)
{
doSomethingAwesome(outImg, inImg);
if (beExtraAwesome != null && beExtraAwesome) {
doSomethingEvenMoreAwesome(outImg);
}
return outImg;
}

}
```

We could express such Java types as modules by creating a new `OpModule` and `OpInfo` (similar to `CommandModule` and `CommandInfo`) but which understands the conventions above, and driven by a new `OpFinder` which scans `OpNamespace` plugins for appropriate public methods.

Maybe this wouldn't actually be simpler. In particular, it might be difficult to express multiple layers of functionality like we have now with `AbstractFunction` etc. But the simplicity above has a certain compelling quality...

Start by reading the existing CommandModule and CommandInfo concepts alongside the proposed OpModule, OpInfo, OpFinder, and OpNamespace roles. No file or test is named; done would require a settled design showing whether type-safe namespace methods can replace duplicate op structures while preserving layered functionality such as AbstractFunction.

Written by the indexing model from the issue text.