Add Op discovery annotations to ImgLib2-algorithm

[gselzer]

This PR uses therapi-runtime-javadoc to declare all static functionality in imglib2-alrogithm as Ops. See this test for how these Ops can be called, and the module imglib/imglib2-algorithm-optest for an example of the structure required to call these annotated methods as Ops.

A new dependency on therapi-runtime-javadoc-scribe is added to the maven compiler plugin. For now, this was added to the imglib2-algorithm POM. Once pom-scijava-base 15.0.0 is propagated to imglib2-algorithm, we can remove almost everything added to this POM by this PR.

The only line needed once we depend on that version of pom-scijava-base is this line, which is responsible for informing therapi-runtime-javadoc-scribe of the set of packages it should process. This line must be changed once we bump the version, as the property used is under a different name.

Using therapi-runtime-javadoc-scribe, JSON files are generated for each file containing javadoc in each package specified by therapi.packages

Open questions:

• Op naming: I have not yet come up with a simple answer to this. I thought it would be nice to name the Ops using the method name, but some methods across different classes have the same name. We could name them using a camel-case "class.method_name", which might match well with how these methods would be called from a static context...
• Which packages should be passed to therapi? We could just pass all packages, but this would retain javadoc that would not be used. We could also only pass packages with Op declarations, but it would be easy to forget to add new packages to this property when ops are declared in new packages. I tend to like the latter a little better, but don't feel too strongly.
• What to do with static methods not conforming to an Op? Many static methods are essentially org.scijava.function.Computers with their output parameter in a position that is not the last one; for these, I have added another method with a different parameter ordering. Other methods do not conform to Op types, such as the HessianMatrix methods. We could easily write a new FunctionalInterface for these guys, but they wouldn't have the support of OpBuilder, adaptation, etc.

TODO:

• [x] The build seems to fail in Java 8, but it runs just fine in Java 11. I still need to figure out why that is... :thinking:

[gselzer]

A running list of static methods that do not conform to functional interfaces in scijava-function:

• The HessianMatrix methods
• The ConnectedComponents.labelAllConnectedComponents that return an int
• The TensorEigenValues
• The Grids methods are interesting. Are they Inplaces? Not really, they aren't actually mutating anything themselves. Are they Consumers?

[gselzer]

@ctrueden @tpietzsch I've fully updated this PR such that it now uses (the unreleased) SciJava Ops Indexer. I can now automatically discover all annotated static methods in an environment containing both a local build of imglib2-algorithm and a local build of the SciJava Incubator. The PR will not build until we release the SciJava Ops Indexer, so I've left it as a draft, but bringing this work up-to-date made me excited for the possibilities of SciJava Ops!

[hinerm]

@tpietzsch In this PR we are discussing the minimum Java version to index libraries with Ops. I'm wondering if there is a need to keep imglib2-algorithm at Java 8, or if going to Java 11 is an option?

[tpietzsch]

@hinerm I don't think there is anything that would break with higher Java versions. As soon as Fiji finally moves to Java 21, (all of) ImgLib2 will too.

[gselzer]

TODO:

There are some methods whose signatures do not conform to the Ops style (e.g. here), where I've written a wrapper method that has been opified. The question, then, is what to do with the original methods. Should we consider deprecating them, @ctrueden?