ServiceLoader-based Discoverer

[gselzer]

This PR introduces a ServiceLoader-based Discoverer, currently able to discover Ops and OpCollections. Suppose we want make a class FooOp in module com.example.foo discoverable by ServiceLoaderDiscoverer; this can be accomplished by following these steps:

1. Make Cls implement Op or OpCollection:

class Cls implements Op {}

2. In module-info.java, provide Op with Cls:

module com.example.foo {
  provides org.scijava.ops.spi.Op with Cls;
}

This PR also adds OpClass to the SPI module, intended to house Op metadata normally stored in a @Plugin annotation, as well as an Op implementation in the SciJava Ops Engine module as a proof of concept.

TODO:

• Consider logging a warning for any class implementing Op or OpCollection that is not declared in the module-info. This should be enforced via a Maven plugin
• Merge Write READMES for each of the current incubator projects  #40, as this branch is built on top of that work.

[gselzer]

NB: An answer to the question: "Why must this depend on SciJava Ops SPI?:

The big reason is to be able to discover OpCollections. We need a marker interface for the ServiceLoader to use in order to discover OpMethods or OpFields. Since we already need scijava-ops-spi for the OpMethod/OpField annotations, we might as well implement OpCollection. But, let's assume that we didn't care about this, and focus only on exposing Classes that we wish to indicate should be Ops.

The ServiceLoader paradigm requires us to provide some interface to make an implementation exposed. Since Ops must be FunctionalInterfaces, we then have but two choices:

1. Provide the FunctionalInterface (e.g. Function)
2. Provide Op

One downside of (1) is that we may pick up Functions that were not intended to become Ops. Of course, since Ops need to have the OpClass annotation anyways, we could filter out any Functions that don't have annotations, so this part could be avoided. The other downside is that this is not extensible: for the ServiceProvider to discover any FunctionalInterfaces we would have to modify this module-info, and thus introduce a runtime dependency on scijava-function or whatever other dependency has the interface. This is not ideal

For these reasons, it is simplest to just use Op and OpCollection. Thoughts?

[ctrueden]

This was a great first step toward using ServiceLoader as an option for discovery of ops. We have discussed and iterated the design several times since then, but the latter work is built on this first iteration, so I am merging this as is, with the understanding that the ServiceLoader-based discovery evolves substantially from this point forward.