Handling collections and map types before running an element converter

[nexx512]

When the custom conversions are checked before collection and map converters, it is not possible to use custom converters for lists and maps.
If a custom converter for a list or a map is defined, it is executed here and not from within the collectionConverter where it should be executed.
So I think collections and maps should be handled beforehand.
Maybe lines 2064-2066 might not be needed ad all as this case is covered with line 2081.

[pivotal-cla]

@nexx512 Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-cla]

@nexx512 Thank you for signing the Contributor License Agreement!

[nexx512]

I extendend this functionality to cover lists and maps of custom types, even allowing for collection converters whose target is not a collection. Being not so restrictive leaved more options to the user to implement custom converters.

It should now be possible to map vavr lists and maps with a simple converter like

@ReadingConverter
public ListReadingConverter implements Converter<List<ListType>, io.vavr.collection.List<ListType>> {
        @Override
        public io.vavr.collection.List<ListType> convert(List<ListType> source) {
            return io.vavr.collection.List.ofAll(source);
        }
}

However for maps to work correctly, the change from spring-projects/spring-data-commons#2517 is required.

I also removed some mapping tests that tested a mapping with a class extending java.util.Map. The extending class however didn't expose a map like interface. So i would say that this case should be covered by a separate class containing a map instead of extending one. This pretty much looked like a good example where aggregation should be preferred over inheritance.

Would be great if someone can have a look at it and discuss it if there are concerns.

[odrotbohm]

Relates to spring-projects/spring-data-commons#2511.