Convert refining

[hinerm]

Improves the Converter framework by moving more default method implementations to AbstractConverter, restructuring the delegation of AbstractConverter to give preference to the Type argument, and extracting the null parameter logic to a dedicated NullConverter which can run at the highest priority, so that other Converter implementations do not need to worry about running ahead of DefaultConverter.

[hinerm]

@dscho @ctrueden @dietzc - these changes are intended to make it easier to implement new Converters. Please let me know if you have any reservations or further suggestions.

[ctrueden]

Thanks @hinerm! I made some comments. Please address as time allows.

One other thing to consider would be deprecating the Class-based signatures in favor of only Type-based ones. (Because a Class is a Type, so you can still use them that way.) And the AbstractConverter layer could have a protected Class<?> raw(Type type) method that just returns GenericUtils.getClass(type) for maximum convenience. I guess the only downside would be that Type has no generic parameter, so the <T> T convert(Object, Class<T>) signature would become less type-safe... but we could still keep that one undeprecated then.

[hinerm]

TODO summary:

• Deprecate convert(Class, Class) style signatures.
• Move null logic to convert(Object, Class) in NullConverter.
• Add unit tests for primitive types, including "null" values
• Test both ConvertService and individual Converters
• Test expected canConvert == false scenarios as well, and not just the positive cases.

[hinerm]

@ctrueden @dscho @dietzc I added the tests that made sense to me, and I think we are at at a minimal amount of work for implementing new Converters.

I think this is ready to merge but wanted to provide a final chance to object.