ClassUtils: move deprecated methods to the bottom
Add utility class with generic type methods

This class recapitulates some of the functions from ConversionUtils
and ClassUtiles, as well as adding new functionality. The previous
methods will be deprecated in favor of those in this class.
Deprecate methods now available in GenericUtils
ClassUtils: tweak javadoc style
ClassUtils: refactor setValue method
ClassUtils#setValue: use more exact field type

Rather than calling field.getGenericType(), let's use the superior
GenericUtils.getFieldType method to get the more exact generic type.
Update unit tests for GenericUtils

This converts the tests of now-deprecated methods from ClassUtils and
ConversionUtils to test the analogous GenericUtils methods instead.
Merge branch 'generic-utils'

This branch reorganizes the lower-level generics-related helper methods
of ClassUtils and ConversionUtils into a dedicated utility class:
GenericUtils. The old method signatures have been deprecated.

The original idea was to use some of these methods to assist with better
ObjectIndex lazy object resolution, but it turns out that even with
clever use of generics reflection, it is not tenable to reliably detect
the type from the LazyObjects instance alone. So the new features of
GenericUtils, while very nifty and probably useful in the future, are
not in immediate use anywhere within SciJava Common.
ObjectIndexTest: improve getAll() test coverage

Specifically, we test that lazy object resolution works in conjunction
with a call to getAll(), to ensure that pending objects get resolved.
AbstractSingletonService: use more specific type

The LazyObjects instance will definitely return a collection of objects
of type PT, not just Object. This distinction is important now that the
ObjectIndex is more selective about which pending objects it resolves.
LazyObjects: add getType() method

This breaks backwards compatibility, so bumps the development snapshot
version to 3.0.0.

The rationale is to make it possible for the ObjectIndex to better
discriminate which objects should be resolved for a particular call to
ObjectIndex#get(Class). The current behavior is to resolve _all_ pending
objects with _any_ call to get(Class), which is generally suboptimal.
ObjectIndex: only resolve relevant pending objects

If a pending object will not be of a type compatible with the
requested type, then skip resolution of that pending object.

This improves performance of the get(Class) and getAll() methods in
cases where there are a large number of pending objects in the index.

It also helps to eliminate difficulties like those in issue #90.
ObjectIndexTest: add a lazy object resolution test

This tests that the addLater method works in conjunction with calls to
get(Class). The logic is nontrivial because we only want to resolve
pending objects when the types are compatible with the requested one.