Add type hierarchy for typed plugins

A TypedPlugin is an ImageJPlugin with a particular associated data type
(which can be queried via the Typed interface).

For example, DragAndDropHandler<D> will extend TypedPlugin<D>, since
each DragAndDropHandler has an associated data type it handles.

A WrapperPlugin is a specific kind of TypedPlugin which wraps a
particular instance of its associated data type.

For example, View<D> will extend WrapperPlugin<D>, since each View
wraps a particular sort of data object.
Add a layer for managing typed and wrapper plugins

This layer provides abstract base classes which ease implementation of
services following the "wrapper" and "handler" plugin patterns.
DragAndDropService: use HandlerService layer

This reduces the amount of boilerplate code.

There is still some repetition, mostly to make the javadoc more
intuitive.
InputWidget: rename isCompatible to supports

This name is more consistent with the imagej.Typed interface (even
though InputWidget does not currently implement that interface).
InputPanel: rename isCompatible to supports

This name is more consistent with the imagej.Typed interface (even
though InputPanel does not currently implement that interface).
Use a more succinct "javadoc override" note
ImageJPlugin: tweak javadoc

It is easier to read "@Plugin" than "@org.scijava.plugin.Plugin" in the
javadoc, so we do that instead. Also fix a small typo.
AbstractTypedService: remove abstract ctor layer

Constructors in Java have some properties which make them a bit unwieldy
with inheritance: in particular, non-default constructors are not
automatically available to subclasses. Further, including a non-default
constructor in an abstract superclass forces a compile-time requirement
on subclasses to provide at least one constructor of their own.

To avoid these difficulties, the AbstractTypedService's "convenience
constructor" was actually not much of a convenience. So it has been
removed in favor of requiring concrete subclasses to implement the
getType() and getPluginType() methods directly. The amount of
boilerplate ends up being similar, but without introducing any
non-default constructor messiness.
Add PTService to the service interface hierarchy

A PTService is any service responsible for managing a specific sort of
ImageJPlugin. This layer was missing previously; there was TypedService
for managing TypedPlugins, but not all ImageJPlugins have an associated
generic parameter (nor should they).
Typed, HandlerService: API tweaks

The Typed#supports method is now actually typed on the generic
parameter, rather than accepting any Object. This made things much
more elegant in several places.

The HandlerService#getHandler method is now typed directly with its DT
and PT parameters, rather than as extension points. The extensions were
unnecessary and introduced additional complexity. The return type of
getHandler was also not guaranteed to be a PT at compile time, which was
extremely unintuitive and silly.
HandlerService: add Typed#supports jdoc override
Add SingletonService and SingletonPlugin

The SingletonService interface is more general than a HandlerService,
but more specific than a PTService. Specifically, it describes a service
which manages stateless plugins of a specific type meant to be
instantiated as singletons (i.e., SingletonPlugins).
Adjust javadoc to match that of SingletonService
HandlerService: extend SingletonService

This change alters HandlerService to extend the new SingletonService in
addition to TypedService. It also introduces a corresponding dedicated
HanderPlugin for clarity and consistency, which is both a
SingletonPlugin and a TypedPlugin.

The DragAndDropService (which was already a HandlerService) has also
been updated accordingly to reflect the updated HandlerService API.
TextService: extend HandlerService

TextFormat is now a HandlerPlugin<File>.
TextService is now a HandlerService<File, TextFormat>.

Conceptually, both of these things were already true; this change just
formalizes it using the handler type hierarchy, which standardizes the
nomenclature to match the handler pattern.
Platform: generalize target platform API

A platform can now identify itself as a target using any arbitrary
criteria by overriding the isTarget() method.

Note that the default implementation in AbstractPlatform still works
exactly the same as before, based on regex matching of five common
characteristics of the runtime.
PlatformService: use SingletonService API

Platform is now a SingletonPlugin.
PlatformService is now a SingletonService<Platform>.

Conceptually, both of these things were already true; this change just
formalizes it using the singleton type hierarchy, which standardizes the
nomenclature to match the singleton pattern. It reduces boilerplate and
makes it semantically clear that the PlatformService manages singleton
plugins of type Platform.
Update to pom-scijava 1.42

This update bumps scijava-common from 1.3.2 to 1.4.0, which provides
access to the new org.scijava.plugin.HasPluginInfo interface.

This change also makes necessary corresponding changes to the Tool
interface, AbstractTool base class, and affected downstream code, since
Tool previously had an incompatible getInfo method signature.
ThresholdService: use SingletonService API

ThresholdMethod is now a SingletonPlugin (and was renamed from
AutoThresholdMethod).
ThresholdService is now a SingletonService<ThresholdMethod>.

Conceptually, both of these things were already true; this change just
formalizes it using the singleton type hierarchy, which standardizes the
nomenclature to match the singleton pattern. It reduces boilerplate and
makes it semantically clear that the ThresholdService manages singleton
plugins of type ThresholdMethod.
DefaultThresholdMethod: remove unnecessary parens