IJHacker: optionally prevent batch mode from exiting

When running ImageJ in batch mode from Java code, we might not want it
to exit always. Unfortunately, there is no way to do so with plain
ImageJ, hence we add code to the IJHacker to handle the command-line
option '-batch-no-exit' that will prevent ImageJ#main from exiting.

This is very useful for testing.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix handling of NoClassDefFoundErrors again

The original fix in 'Modify ImageJ 1.x to avoid overzealous handling
of NoClassDefFoundErrors' was not very well tested by yours truly:
it missed out on the rather important fact that the exception's
message is *not* the class name that was not found in every case: if
a .class file was found in the expected spot which describes another
class (e.g. in a different package), the exception's message reads:
package/Class (wrong name: XYZ).

This was reported as Fiji bug 576 by Jan Eglinger.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add an integration test for running bare plugins

A bare plugin is a plain .class file in the plugins/ directory. There is
a problem with that, though: placing a .class file into a subdirectory
does not say whether the class is supposed to live in the package
corresponding to the subdirectory's name, or whether the file was just
put there to place the corresponding menu item into a submenu of the
Plugins menu.

We fixed this so many times that this developer got really tired of
it, so let's have an integration test that is run by Maven so that
we can really, really be sure to catch breakages early.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
While at it, test IJ.runPlugIn on plugins with missing dependencies

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make the report about a changed method signature less confusing

ImageJ users -- for which this handling caters -- usually do not
understand exceptions. Hence we tried to give a bit more intuitive
information about the case when a method signature changed --
probably due to conflicting class path entries. However, we still
started the report with an exception which confuses the heck out
of non-programmers.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Refactor the fiji-compat integration test a little bit

The newly-introduced copyJar() method is actually not needed, but was
developed in the course of developing an additional integration test,
so we might just as well keep it for future use.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add an integration test for our NoSuchMethodError handling

We try to be helpful in identifying situations where contradicting
.jar file versions are in the class path. Since this is such a useful
tool in particular with Bio-Formats, let's let Maven make really sure
that this continues to work as expected.

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