LegacyEnvironment: Allow augmenting PluginClassLoader's class path

This adds ia method to the LegacyEnvironment that lets the user add .jar
files to the class path of the plugin class loader. That allows ImageJ
1.x environments to have their own encapsulated sets of plugins.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyEnvironment#addPluginClasspath: support adding directories

The biggest shortcoming of ImageJ 1.x is a lack of support for adding
*unpacked* plugin .jar files (as you would want when running inside an
IDE, or when running unit tests as part of a Maven build).

This commit adds support for them.

Note: the common workaround was to add the plain .class files into the
plugins/ directory of ImageJ 1.x, but that work-around falls flat on a
couple of accounts: lack of support for plugins.config (and therefore
plugin classes whose names have *no* undercore), lack of support for
dependency .jar files living somewhere completely different, the problem
that using unpacked .class files in plugins/ tests a different code path
than the intended usage, etc.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Support adding a plugin class path given a ClassLoader

Sometimes you already have a class loader that knows where to find your
ImageJ 1.x plugins you want to run inside the legacy environment.

This commit adds LegacyEnvironment#addPluginClasspath(ClassLoader) to
support that use case (the plugin class loader has to load the plugin
classes separately from the given class loader, of course, so they know
about *this* legacy environment's ImageJ 1.x).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make sure that LegacyEnvironment#addPluginClasspath() works

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