WIP: working on displaying @Output ImagePlus

TODO: remove ij.* imports if possible?
fix: correct LegacyDialogPrompt implementation
DefaultLegacyHooks: simplify plugin creation

The PluginService can be used to simplify creation of a plugin from a
PluginInfo.

Noted by ctrueden
DefaultLegacyService: update isLegacyMode check

It was not really accurate to use the legacyMode flag, now that we have
a LegacyUI.

When the LegacyUI is active we may be in "IJ2 mode" but still want the
legacyService.isLegacyMode method to return true.

So now we will check the IJ1Helper instead.
LegacyUI: implement show

Implementation of show that is very similar to that in
AbstractUserInterface.

The main difference is that if the obtained DisplayViewer is an
ImagePlusDisplayViewer, we can just call its view method and be done
without the need to create a display window, etc... as the ImagePlus
will handle it.
TEMP: open image test case

test an IJ2 plugin with an ImagePlus @Parameter, type=OUTPUT.
Fix: legacy display - remove unnecessary class

whoops, accidentally copied this and committed it.
TEMP: get SwingUI interface. Replace with release coupling
WIP: implement LegacyImageDisplayViewer
TEMP: update to ij1-patcher 0.4.3-SNAPSHOT
Update packages for 0.4.0

The imagej.legacy package is now net.imagej.legacy for consistency.
Updated all imports to match the new package structure.
Add a plugin type to intercept ImageJ 1.x' opening images

This plugin type will need to be implemented by all plugins wanting
to have a say how an image is opened.

It is our design to improve on HandleExtraFileTypes; Now developers
can extend ImageJ 1.x' image opening without stepping on each others
toes, badly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
DefaultLegacyHooks: support LegacyImageOpener plugins

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

LegacyImageOpener was deemed too specific - we would like to be able to
open arbitrary sources using ImageJ2's opening mechanism. Thus what we
really want is a "LegacyOpener" and a DefaultLegacyOpener
implementation that will run the IJ2 OpenFile command on a given input.
DefaultLegacyHooks: intercept 3-param runPlugIn

Intercepting the 2-parameter ij.IJ.runPlugIn was insufficient for
intercepting commands executed from menu items, as these all directly
use the 3-parameter runPlugIn signature (which is trivially delegated to
from the 2-parameter signature).

Thus it makes more sense to intercept the 3-param signature, allowing us
to override behavior from any menu item.

NB: an IJ1Helper is used to shelter the ij.plugin.Commands import from
the DefaultLegacyHooks.
DefaultLegacyHooks: intercept open command

If the ij.plugin.Commands open method is executed, we will now intercept
and delegate to the interceptOpen method, allowing LegacyOpeners to be
used.
DefaultLegacyOpener: avoid display postprocessing

We want to run the IJ2 open command with all preprocessors (and the
capactiy to include postprocessors) except DisplayPostprocessors, as
these will cause the IJ2 GUI to display an image.. which will then
typically be displayed again by IJ1.

To work around this, we blacklist DisplayPostprocessors by removing them
from the PluginIndex while running OpenFile. The postprocessors are then
returned to the index after execution.

When ready, the LegacyUI should handle this more appropriately.
LegacyUI: set priority to HIGH

This ensures that if the UI is present, it will be preferred.
Refactor ImagePlusCreator

It should be possible to get an ImagePlus back with just a Dataset. If
the Display is available, we can do extra harmonizing.
DefaultLegacyOpener: refactor to lean on framework

If a requested image is to be displayed, we can now just let the
established LegacyUI framework handle its display.

If not, we can use the ImagePlusCreator API to generate and register new
ImagePlus instances for us, without displaying them.