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
CommandService: extend PTService<Command>

The CommandService is a service that manages Commands, after all.
WidgetService: extend WrapperService

WidgetService is now a WrapperService<WidgetModel, InputWidget>.
InputWidget is now a WrapperPlugin<WidgetModel>.

Conceptually, both of these things were already true; this change just
formalizes it using the wrapper type hierarchy, which standardizes the
nomenclature to match the wrapper pattern. It reduces boilerplate and
makes it semantically clear that the WidgetService manages wrapper
plugins of type InputWidget.
CalculatorService: extend SingletonService

CalculatorService is now a SingletonService<CalculatorOp>.
CalculatorOp is now a SingletonPlugin.

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 CalculatorService manages singleton
plugins of type CalculatorOp.
OptionsService: extend PTService<OptionsPlugin>

Since the OptionsService is responsible for managing OptionsPlugins,
this hierarchy is natural.
ToolService: extend SingletonService<Tool>

ToolService is now a SingletonService<Tool>.
Tool is now a SingletonPlugin.

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 ToolService manages singleton
plugins of type Tool.
Add TODOs for a few service structure issues

It would be nice for these services to extend the appropriate layer of
the service type hierarchy, but it is not urgent to do so.