LegacyTestUtils: the LegacyInjector's and ij.IJ's class loader must match

Otherwise, LegacyInjector's setLegacyService() tries to assign a new
instance of DummyLegacyService to ij.IJ._service, but that fails because
the DummyLegacyService and the type of ij.IJ._service were loaded with
different class loaders and are therefore incompatible.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
CodeHacker: make sure that a PluginClassLoader is instantiated

Otherwise, ij1.plugins.dirs is not heeded!

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ij-legacy tests: reinstate the Thread name after IJ.run()

This is in the same spirit as fbbdf4b5(Fix (ij-legacy tests: make sure
that a main class is found)): AppUtils#getBaseDirectory requires the
main thread to be called 'main'.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Turn the ij-legacy class loader integration into a simple unit test

It is much easier to debug a simple unit test than integration tests.
In the case of the ij-legacy class loder tests, we made them integration
tests only so that we would have a fresh class loader, unencumbered from
any patched or unpatched ImageJ 1.x classes.

But we just needed to refactor the legacy headless tests which created
exactly such a class loader.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ij-legacy: make sure GenericDialogs are disposed in macro mode

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ij-legacy: make sure NonModalGenericDialogs don't wait forever in macro mode

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyTestUtils: use better method to construct fresh class loader

We can simply reuse the current class loader's URLs: as we only run
this code in unit tests, we can be sure that this is a URLClassLoader
with local URLs only.

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