AbstractInputHarvester: tweak style
ClassUtils: add canConvert and canCast method sigs

These new signatures take a source class and a destination type, rather
than a source object. This is useful for testing whether two types are
compatible without having an actual instance of the class in question.
ClassUtils: tweak a couple of minor things
InputWidget: add generic parameter for widget type

This simplifies the subinterface declarations by removing the
type-narrowed getValue() methods.
InputWidget: add new API methods

The setModel(WidgetModel) method allows the WidgetModel to be assigned
after construction.

The isCompatible(WidgetModel) method checks whether a given widget is
appropriate for use with a particular widget model object. For example,
a number slider widget would be appropriate for use with a WidgetModel
housing a ModuleItem of type Number, and NUMBER_SLIDER WidgetStyle.

These methods will be important later for the extensible widget
mechanism, so that we can construct initially "empty" widgets and then
test them for compatibility with each module input to be harvested.
Unify widget add method signatures

This is in preparation for the eventual removal of these special case
methods in favor of a fully extensible mechanism.
Remove message label hack

You can achieve the same thing by specifying such a label explicitly in
the message of your plugin. I don't think it makes sense to force the
label to always appear no matter what.
Remove unused choice index accessor methods
Split persistence handling to separate preprocessors

Previously, the persistence logic was mixed in with the input harvester,
when it should really be handled separately, with persisted values
loaded prior to input harvesting, and saved after input harvesting is
complete.
Tool: move javadoc to better location

It makes more sense in the Tool interface than the in the AbstractTool
base class.
Make plugin processors contextual

This addresses a long-standing issue where plugin processors could not
access ImageJ services without making deprecated, static method calls.
Eliminate deprecated ImageJ#get calls

This is possible now that plugin processors are contextual.
Make ModuleRunner contextual

(It already was, but without implementing the interface.)
Create InputWidget UIs after construction

This migrates the creation of UI-specific elements into a dedicated
InputWidget#initialize(WidgetModel) method, rather than doing it during
construction.

This change allows for instantiation of widget instances without
necessarily creating any UI elements. It will be useful later for
dynamic discovery and selection of widgets; we can create a widget,
inquire as to whether it is compatible with a given WidgetModel, and
only initialize its UI-specific objects if so.
Rework widget system to be discoverable/extensible

There is now a widget service that is responsible for creating widgets
matching required criteria. Much case logic has been removed in favor of
dynamic discovery of widgets.
AbstractInputHarvester: eliminate deprecated call

This pushes the Contextual implementation from
AbstractInputHarvesterPlugin to AbstractInputHarvester, so that the
latter can access the WidgetService.
Fix widget compatibility logic

The old logic was totally wrongheaded. This commit restores the logic to
be very similar to how it was before the change to extensible widgets.

One problem was the use of ClassUtils#canConvert to detect whether the
widget could handle a particular parameter type. For example, the
TextFieldWidgets were being erroneously chosen for many different
parameter types such as ColorRGB, because according to
ClassUtils#canConvert, any object can be trivially converted to a String
using Object#toString().

Really, a TextFieldWidget should only be chosen if the type actually
*is* a String (or a char or a Character), and not merely because the
parameter type could be converted to a String.

Another problem was the implementation for choice and text field
widgets; the former should only claim compatibility if the parameter
type is a string, while the latter should only claim compatibility of
the parameter is not multiple choice.
Fix handling of object pool for object widgets

The widget model now keeps the pool of objects cached, in case the
linked widget needs to make use of it.
ParameterTester: add message visibility parameter

This tests the dialog's message/label feature.
Reimplement support for messages as parameters

There is now a MessageWidget that is used in the case of MESSAGE
visibility parameters.

This commit introduces two new flags for widgets: isLabeled and
isMessage. If isLabeled is false, the label prefix is omitted and
instead the widget spans the entire dialog. This could be useful beyond
just messages, for things like graphs, charts or other embedded UI.
If isMessage is true, then the widget counts as a message-only widget,
which can affect how the input dialog is rendered. In particular, if
there are only message widgets, then the dialog may show a "question" or
"information" icon; see SwingInputHarvester for details.