CodeHacker: add a way to commit non-IJ1 classes into the given class loader

We add three classes in the legacy patching: LegacyHooks,
EssentialLegacyHooks and HeadlessGenericDialog. These must be known to
the class loader, of course.

With LegacyHooks, we want to make it accessible both to the calling
classes and ImageJ, so it makes sense to share that interface (via the
slightly method to return it from findClasses(), violating the
convention that a class loader should only return classes whose
associated class loader is in its hierarchy).

With EssentialLegacyHooks and HeadlessGenericDialog, this is not
possible: they access the ImageJ 1.x classes themselves, and therefore
they would access the *wrong* ImageJ 1.x classes if we were to reuse
those classes from a different class loader. Therefore, we need to
commit those classes to the same class loader the ImageJ 1.x classes
are living in.

This makes only a difference if the class loader that gets passed to
CodeHacker is a different one than the one which loaded CodeHacker.
That is exactly the way we intend to handle things in the near future:
to be at least able to encapsulate ImageJ 1.x "instances" by loading
them into special-purpose class loaders.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Avoid using ImageJ 1.x classes in LegacyHooks directly

Since we want to share the LegacyHooks interface between the
LegacyClassLoader and the ClassLoader that performed the ImageJ 1.x
patching, the LegacyHooks interface cannot pass an ImagePlus
instance around: it would be incompatible (by reference, the
LegacyHooks' reference to ImagePlus would be loaded from the class
loader that loaded the LegacyHooks interface itself).

Side-step the whole issue by passing Object instances around, not
ImagePlus instances.

This also opens the door for the future when we might want to have a way
to translate between ImagePlus instances loaded into different class
loaders.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
fixup! Move some of the former LegacyExtensions into the ImageJ2-specific hooks
Add two more methods to the legacy hooks

The whole idea of the legacy patching is to provide more extension
points than ImageJ 1.x offers on its own.

One very important extension point required by literally every
application that might need to make use of extension points is a
callback when ImageJ 1.x was initialized.

There are possible chicken-and-egg problems here, with the legacy hooks
living in ImageJ 1.x' jars/ directory: the legacy hooks can only be
loaded using ImageJ 1.x' PluginClassLoader, therefore they cannot be
installed before ImageJ 1.x was initialized.

To remedy that situation, we change the EssentialLegacyHooks (i.e. the
hooks installed initially) to interpret the system property
ij1.patcher.initializer as name of a class implementing the Runnable
interface, to be called upon initialization.

Of course, this is too late for some of the extension points (such as
setting the window title of the ImageJ 1.x main window), but that cannot
be helped: we simply have no way to access classes in the
PluginClassLoader before that class loader's class path is determined --
which happens *during* the initialization of the main window, i.e.
*after* the window title/icon are set.

It is therefore the duty of the initializer to fix that, first thing
(unless we are running in batch mode, in which case IJ.getInstance()
will be null).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make sure HeadlessGenericDialog & EssentialLegacyHooks are loaded into the correct class loader

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
fixup! Avoid using ImageJ 1.x classes in LegacyHooks directly
fixup! Add two more methods to the legacy hooks
wip
WIP: Add a default legacy initializer class

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