SystemInformation: print out available services
MacOSXPlatform: use term "commands" not "plugins"
SortedObjectIndex: add a very simple unit test
ObjectIndex: add toString() method for debugging
Improve docs for ObjectIndex and PluginIndex

The documentation now explains much more thoroughly about what the
object index does, and how it works. It also clarifies that even though
each object index has a base class of objects being classified, the type
hierarchy beneath which they are classified may be distinct from that
base class's type hierarchy. In particular, the plugin index classifies
its PluginInfo objects beneath their plugin type hierarchies rather than
the typ hierarchy of PluginInfo itself.
ServiceIndex: add a very simple unit test
ObjectIndexTest: fix expected/actual assert order

This commit also uses assertEquals and assertSame where appropriate
instead of assertTrue with equality tests.
ObjectIndexTest: add another check to testGetAll

This tests an intermediate layer (Number) of the type hierarchy.
ClassUtils: add compare(Class, Class) method

This method compares the two classes by fully qualified name, but does
not take ClassLoaders into account.
Priority: flesh out javadoc for compare method
AbstractUIDetails: improve compareTo logic

The logic now goes beyond just Priority.compare, also comparing classes,
then names, then labels. It is still not guaranteed to provide an
ordering consistent with equals, though.
SortablePlugin: improve compareTo logic

The logic now compares classes as a fallback if the priorities are
equal. It also handles comparisons with null properly. The ordering is
still not guaranteed to be consistent with equals, though.
ObjectIndex: use ClassUtils#compare in toString

This is slightly easier to read and more efficient too.
ObjectIndex: improve efficiency of contains method

The previous version called List#contains on the "all" list, but it
makes more sense to check the list specific to the object's class, since
it will likely be much shorter (in some cases, with only one element!).
ObjectIndex: allow duplicate items

The object index uses lists internally, and the restriction that each
item could only be added to the index once was unnecessary and perhaps
counterintuitive. Certainly it impacted performance negatively, since
the lists had to be checked every time for the item's presence.

Within ImageJ's current uses of ObjectIndex, it should not be the
case that any item appears more than once anyway, so this change is
unlikely to impact ImageJ's behavior directly. There may be a situation
in the future where it is nice to have duplicate items. And in the case
where duplicate items are *not* desired, downstream code can check
itself for them using contains before adding to the index.
SortedObjectIndexTest: add test for duplicates

We want to verify that if the same object is added (and/or removed)
multiple times that the index behaves as expected.
PluginService: improve getPluginsOfClass(Class)

Specifically, the performance should be better now. We use the given
Class reference to look up the plugin type as given by the @Plugin
annotation, and then limit our search to PluginInfos of that type only.

Note that this is now feasible since we recently switched the @Plugin
annotation to a RUNTIME retention (it was COMPILE time before, meaning
that javac would erase it after running SezPoz on it).
PluginService: improve documentation

Specifically, the getPluginsOfClass(String) method must scan the entire
plugin index for matches, because we want to avoid loading the class
given by the className parameter.
OptionsService: instantiate options more robustly

We now always lean on the internal DefaultOptionsService#createInstance
method for creating instances of OptionsPlugins. This ensures they are
completely populated with their context, priority and service
parameters.

Because we do this, we also no longer need to run the
ServicePreprocessor on them explicitly afterwards, because their
services will already be populated.

Lastly, we invoke the remaining desired preprocessor plugins explicitly
rather than via a ModuleRunner, because we do not want any events to be
issued with respect to those preprocessing steps; the processing is
merely internal to how OptionsPlugins work.