Implement LegacyImageDisplayViewer

Adds a new DisplayViewer for rendering ImageJ2 outputs via ImageJ1.
Updates the LegacyUI to account for the new DisplayViewer
implementation.

Currently the LegacyImageDisplayViewer handles Data and Dataset
@Paramter(type = Output) fields. Data is wrapped in an ImagePlus and
displayed in the ImageJ1 framework using ImagePlus.show.

Using this new DisplayViewer, it should now be possible to run ImageJ2
commands with Data and Dataset outputs and have them display properly in
legacy mode.
Update imagej.legacy packages

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.
Move towards standardized contextuality

The various creators, translators and harmonizers are in different
states of being Contextual or not. Often, an unneeded service was being
passed in a constructor just to get its context. This patch makes things
that are Contextual take a Context in their constructor. Things that are
not Contextual just take the service they need.
LegacyUI: implement choose file

Added an implementation for the chooseFile method. This is almost
identical to that of the SwingUI, and should potentially be consolidated
(except that we want to use the ImageJ application frame).
LegacyImageDisplayViewer: set active display

Since we aren't using the framework for actually displaying our legacy
images (they are rendered via ImageJ instead), we need to manually
inform the IJ2 framework what the active display is so it can be queried
by interested parties.
Add LegacyDisplayViewer interface

This is a marker interface. As both the ImagePlus and LegacyImage
display viewers do not use the framework for the actual image rendering
(and thus do not have a display window) they are treated specially by
the LegacyUI. A common interface simplifies the test for these display
viewers.
Apply code cleanup to LegacyUI

Added javadoc and applyed the ImageJ2 style template via Source > Clean
Up in Eclipse.
Apply source cleanup to net.imagej.legacy.plugin

Applied the ImageJ2 code style templates via source cleanup in Eclipse.