Improve javadoc for update and rebuild events
Refactor SwingUtils dialog logic into SwingDialog

The new class is more object-oriented (avoids statics), enabling the
addition of new functionality such as setModal/isModal, without changing
method signatures.
Use SwingDialog instead of deprecated SwingUtils
Add an interactive command base class for e.g. B&C

The base class listens for changes to the active display, and keeps
linked parameters in sync with those changes.

The input harvester will also special-case this sort of command to use a
floating (non-modal) dialog box instead of a blocking (modal) one.
Make interactive commands non-modal
BrightnessContrast: extend InteractiveCommand
Make mutable modules into first class citizens

Previously, the API was specific to the DefaultModule, DefaultModuleInfo
and DefaultModuleItem classes, and not defined in any interfaces.

This made it more difficult to deal with Java single inheritance, since
anything wishing to provide the module mutation methods *must* extend
the DefaultModule* classes.
DynamicCommand: register event handlers properly

The recent refactoring to make registration of event handlers more
automatic unfortunately left out DynamicCommands, which do not extend
ContextCommand.

We add an EventUtils convenience class to minimize the repetition (which
is necessary because Java only supports single inheritance).
Add a CommandUtils class to avoid repeated code

This is very similar to the recently added EventUtils. Both of these
classes merely delegate to the respective service of a given context...
but only if such a service exists.
AbstractImageDisplayViewer: fix NPE

This change makes the PanZoomEvent handler consistent with the other
event handlers, and avoids an NPE when the associated display is null.
Make SwingDialog#show work with non-modal dialogs

JOptionPane#showDialog does not return an Integer in the
case of a non-modal dialog; instead it returns a String:
JOptionPane#UNINITIALIZED_VALUE.

We now return our own integer constant, NON_MODAL, in that case.
And in other non-Integer cases, we return another new constant: UNKNOWN.
AbstractInputHarvester: extend AbstractContextual

Input harvesters are contextual, and the abstract base class had no
other superclass, so we might as well use the contextual base class to
reduce boilerplate code.
SwingInputHarvester: tweak style
InteractiveCommand: make preview delegate to run

Whenever an interactive command's parameters change, run is called.
This is hopefully more intuitive than "preview", especially since run
gets called when the non-modal dialog initially appears, too.
BrightnessContrast: use a clearer callback method

This adds slightly more code, but is more consistent, since each
callback method is now named xyzChanged, and the initializer is still
called initValues.
InputWidget: fix typo in documentation
SwingDialog: remove buttons if dialog is non-modal

This brings the behavior of interactive commands in line with how ImageJ
1.x does things. It doesn't make sense for a non-modal dialog to have OK
and Cancel buttons, since there is nothing that can consume the result.

Note that it is still possible to have buttons in a non-modal dialog
by using the imagej.widget.Button class; see
imagej.core.commands.debug.ButtonDemo for an illustration.
SwingUtils: tweak style and fix warning
ClearRecent: services are not outputs

I think I see what I was thinking here: when performing actions that
manipulate the state of the service, it could be argued that that
service is an "output" similar to how ImageDisplays are ItemIO.BOTH when
the command manipulates them. But for now, service outputs are
unsupported anyway, and there is really no need to chain them along in a
workflow pipeline anyway, since they always get populated properly at
each step of the way.
Merge branch 'interactive-commands'

This branch adds a new base class, InteractiveCommand, for commands that
wish to produce a floating (non-modal) input dialog. The
BrightnessContrast plugin has been updated to use it, as an example.

This new type of command should make it possible for us to support these
sorts of floating dialogs, similar to ImageJ 1.x.