Merge branch 'updater-gui'

This fixes a couple of issues, most notably with WebDAV uploading.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Rename DefaultModule* to DefaultMutableModule*

The reason is that these default implementations implement not only the
Module* interfaces, but the MutableModule* ones. It is misleading to
call them DefaultModule* when in fact they are more than that.

This change also splits the old DefaultModuleInfo into two parts: an
AbstractModuleInfo base class, and a DefaultMutableModuleInfo default
implementation. This brings it in line with the Module and ModuleItem
interfaces, which also have both an abstract base class and a default
mutable implementation.
ModuleInfo: add type-safe item accessors

It is now possible to ask for an input or output item by both name and
type. The behavior is the same as asking only by name, except that if
the item of that name exists but is the wrong type, the method throws an
IllegalArgumentException. In this way, there is now a compiler-friendly
way to ask for inputs and outputs without explicit casting.
MutableModuleInfo: items are not always mutable

It is helpful to make an explicit note in the javadoc that a
MutableModuleInfo does not always have mutable module items (i.e.,
MutableModuleItems). In particular, it is very possible for downstream
code to add items via addInput(ModuleItem<?>) which are not mutable.
MutableModule: explicitly promise a mutable info

It was always the case that our existing MutableModule implementation
(DefaultMutableModule) has a MutableModuleInfo. But it was not
previously guaranteed at the interface level, only in the
DefaultMutableModule implementation itself. It is nicer to guarantee it
at the interface level to avoid downstream code needing to cast and/or
rely on something being an instance of the default implementation.
Remove crappy and confusing shell scripts

I originally added these scripts before we had integrated the ImageJ
launcher. Then I left them there because (I thought) they might serve as
a convenient alternative to launch ImageJ in a "quick and dirty" way if
the launcher didn't work for some reason. But that is really a bad idea,
because the way they construct the classpath differs, and will not work
correctly in many cases due to ImageJ's usage of custom class loaders.

So let's just get rid of them, to avoid problems and confusion!
DynamicCommandInfo: add type-safe item accessors

These accessors allow you to explicitly obtain a MutableModuleItem<T>
for a named input or output (together with its Class<T> type). Of
course, if the item is not a MutableModuleItem, a ClassCastException
will be thrown, but these new methods allow downstream code to access
known-mutable items (particularly those explicitly declared as
@Parameters) in a friendlier way, without ugly casts or
@SuppressWarnings("unchecked") annotations.
DynamicCommandInfo: fix incomplete wrapping bug

The issue is that the Validated methods were not being wrapped, so the
DynamicCommandInfo inherited from its superclass DefaultModuleInfo,
which always reports itself as valid (isValid() returns true always).

Thanks to Aivar Grislis for discovering this bug!
Merge branch 'mutable-modules'

This branch cleans up the MutableModule* type hierarchy, and adds some
convenience methods for use by commands which extend DynamicCommand.
ModuleInfo: make interactivity a 1st-class citizen

At the imagej.module layer, there is now a ModuleInfo#isInteractive()
method to query whether a module is intended to be run interactively.

At the imagej.command layer, there is now an Interactive duck-type
interface (similar to Cancelable and Previewable) which indicates a
Command is supposed to be run interactively. There is also an
InteractiveCommand base class with the necessary plumbing for
interactive commands in general. And the ij-data project now has an
imagej.data.command.InteractiveImageCommand which extends
InteractiveCommand with support for DatasetView and Dataset input types.

Lastly, this change migrates the old InteractiveCommand (which is now
InteractiveImageCommand) out of the ij-commands project, where it was
previously buried.
ContextCommand: fix error in javadoc
PlaneHarmonizer: always set current slice pixels
Launcher: special-case Micro-Manager

We want to support Micro-Manager better, so let's add mm/<platform>/ to
the library path in addition to lib/<platform>/.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Updater: the log service should be final

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Updater: fix a javadoc parameter

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Updater: simplify call

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Updater: avoid deprecated constructor

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Updater: remove unused imports

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Updater: remove unnecessary suppression

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Updater (Swing): add a couple of default serial IDs

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>