ModuleService: be consistent with run signatures

It makes more sense to always type the Module using generics, when
possible.
Make Instantiable#loadClass return unknown subtype

In general, we cannot guarantee that the actual objects instantiated by
the createInstance methods will be precisely type T, rather than a
subtype of T.

So due to the lack of covariance of generics, the loadClass method must
return a Class<? extends T> rather than a Class<T> specifically.
PluginInfo: remove setClassName(String) method

It was dangerous, unnecessary, and nothing was using it. If something
were to have used it, it could have caused inconsistency and confusion,
especially if multiple ClassLoaders were involved.
PluginInfo: fix possible issue with getClassName()

If PluginInfo#setPluginClass(Class) were called later, then
getClassName() might return the wrong name afterward. Instead, we now
return the actual loaded class's name if available, or the initial
string name otherwise.
PluginInfo: add constructors for plugin Class

These allow construction of PluginInfo objects that wrap an
already-loaded Class object, rather than a String class name which must
later be loaded again (possibly by the wrong ClassLoader).
Remove unnecessary refs to PluginInfo#getClassName

The PluginInfo#toString() method was intended for debugging these sorts
of issues anyway, so it makes sense to use it.
PluginInfo: add getPluginClass method

This method inquires as to the associated plugin class, but without
loading it.
CommandInfo: add constructors for command Class

These allow construction of CommandInfo objects that wrap an
already-loaded Class object, rather than a String class name which must
later be loaded again (possibly by the wrong ClassLoader).
Fix DefaultPluginService#getPluginsOfClass(Class)

The previous implementation overoptimized by limiting the search to only
a subset of plugin types, which could potentially be inappropriate if
the same Class is reused with multiple PluginInfos of different types.

Thanks to Johannes Schindelin for pointing this out!
PluginService: improve getPluginsOfClass methods

The getPluginsOfClass(Class, *) methods now work a bit differently, to
ensure that the resultant PluginInfo objects have not only a matching
class *name*, but also a matching *Class* object. To do this, they first
ensure that the class names match, then load the matching Classes as
needed and exclude the ones whose Class objects differ from the given
one. This is necessary because it is possible to have more than one
Class object for the same fully qualified class name, if the classes
were loaded using different ClassLoaders.

There is also a new method getPluginsOfClass(String, Class) for limiting
the search to a particular plugin type. (This method is analogous to the
getPluginsOfClass(Class, Class) method, which already existed.)
LegacyPluginFinder: use LegacyCommand class

Now that we have a CommandInfo constructor that takes a Class object
directly, we can use LegacyCommand.class directly rather than its name.
Add a test case for the CommandService#run(Class, ...) method

For the moment, this test fails because the command service says:

	No such command: imagej.command.CommandServiceTest

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
CommandService#run: create CommandInfo on demand

It is rather unintuitive for the run methods to fail to execute commands
which are valid, but not registered with the service. So now the run
methods transparently wrap unregistered commands in a CommandInfo.

This fixes the CommandServiceTest tests.
Merge branch 'class-loaders'

This branch makes the PluginService and CommandService much more careful
with operations surrounding Class *objects* versus String class *names*.

In particular, we no longer assume that two classes with the same name
are actually the same Class, but check more thoroughly.

API was added and updated to facilitate these changes, and the places
that invoke PluginInfo#getClassName were reduced as much as possible.