Generalize ConvertService + Converter

[hinerm]

The ancestors of these classes evolved to have API for handling Type and Class separately. This is unnecessary.. we should unify this API by focusing on Type and special-casing Class.

This will simplify things and reduce the number of signatures.

Furthermore the API of <T> convert(Object, Class<T>) is really a holdover from the old uber-conversion mindset. What we should have is:

• A single high-priority (right after NullConverter) castingConverter that handles casting. This implies that low-level converters do not cast, but provide their specific output type.
• Refactor API so converters just implement O convert(I)

[ctrueden]

We should also split the DefaultConverter into several Converter implementations with proper prioritization, to eliminate the monolithic case logic of the current code.

[hinerm]

Also, ClassUtils#setValue uses ConversionUtils. This has the potential for problems within multi-context environments. Essentially this means that ClassUtils - or at least parts of it - should be contextual.

[hinerm]

We should also have a NullConverter that runs first to catch null inputs, and remove the logic to accept nulls from the AbstractConverter layer.

[hinerm]

@dietzc raised a good question - why does convert take an Object and not an I parameter.

Right now the answer, I believe, is to allow accepting collections and primitive arrays of type I as input as well. But maybe we should just always be unwrapping these multi-element inputs and relying on converting the individual elements..?

[ctrueden]

why does convert take an Object and not an I parameter.

Convenience at compile time. It is the same reason that Collection#contains takes an Object instead of an E. I don't think there is any harm in allowing a non-I parameter to be specified.

[ctrueden]

maybe we should just always be unwrapping these multi-element inputs and relying on converting the individual elements

The idea was to create a separate Converter for collections, which recursively leans on the ConvertService framework for individual elements. This will reduce the SLOC count while also making conversions more robust and easier to understand.

[ctrueden]

As part of this work, we should also reconsider the canConvert(Type, Type) style signatures. Right now, they are deprecated, but stuff still uses them. And I think we still need them! At least, the OPS matcher does. So they should really not be deprecated...