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 hiearchy, 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 hiearchy, 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