Support decoding to Collection and Map subclasses

[jyemin]

JAVA-4742

The main complication to adding this feature is that the existing IterableCodec is not able to extend a class with the parameterized types <T, C extends Collection<T>>. The same goes for MapCodec extending a class with the parameterized types <T, M extends Map<String, T>>. The type system prevents this in the face of the default behavior of using ArrayList and HashMap, respectively, for the existing public constructors. Also, since Iterable does not have an add method, it's problematic to add a decode method that supports parameterization with Iterable.

I tried a bunch of experiments to get these codecs to work with this new feature, failed, and went with the following approach:

• Revert the recent changes to IterableCodec and MapCodec that added support for parameterization. Since they are part of the API they can't be removed, but they are deprecated.
• Add new CollectionCodec and MapCodecV2 codecs that don't suffer from the same problems
• Add CollectionCodecProvider and use it in all the default registries ahead of IterableCodecProvider (which has to remain to support case where it actually is an Iterable that is not a Collection. Without this we can't encode anything created by our own com.mongodb.internal.Iterables class, for example. )
• Create instances of MapCodecV2 instead of MapCodec in MapCodecProvider

[rozza]

I'm of the opinion that if we require the IterableCodec / IterableCodecProvider it should not be deprecated but the suggestion to use the CollectionCodecProvider instead works.

If we really want to deprecate it, it might be better to do so it in a separate ticket and refactor our code that requires it and remove it from the default registry (and accept it might break some niche usecases).