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.
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>
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.
WIP: Fix CommandInfo/PluginInfo relationship

The goal here is for CommandInfo to retain the reference to its linked
PluginInfo, if any, and then override key methods to avoid certain
duplication of data structures. In particular, when the CommandInfo
loads its plugin class, that state should also be reflected in the
linked PluginInfo. Otherwise, even after calling loadClass() on the
CommandInfo, the plugin service will not have a PluginInfo in its index
with a reference to the loaded class.