Improve ConstructorConstructor

[Marcono1234]

Fixes #1708
Fixes #2067

Currently the proto module tests are failing. However, arguably this is the "correct" behavior. During deserialization, fields of type com.google.protobuf.Internal.LongList are being deserialized. Previously Gson erroneously created ArrayList instances even though Protobuf's LongList is not related to ArrayList (see #1708). This worked (by accident?) due to how Protobuf's GeneratedMessageV3 is implemented. It does not care about the type of the list.

Now with the changes of this pull request, Gson fails to deserialize LongList. Maybe this could be worked around by not deserializing the field type here, but instead again deserializing a List. But I am not familiar with Protobuf and don't know if such a solution would be reliable (it would probably be as reliable as the current implementation).

For com.google.protobuf.LazyStringList it would probably be possible to register an instance creator which creates a LazyStringArrayList instance.

Any suggestions?

[eamonnmcmanus]

The current behaviour seems hard to understand, but I am concerned if we change it to be more logical we may break projects that are implicitly depending on the way it is now. I ran this PR against Google's internal tests and encountered four failures in four unrelated projects. All appeared to be related to protobufs, some directly via the ProtoTypeAdapter in this project and others via what appear to be modified clones of that class. My inclination is to leave this alone.

[Marcono1234]

Hmm, ok that is unfortunate. I have split EnumMap support into a separate pull request (#2071). If you want you can close this pull request here then, if you don't think there is any chance this will be integrated.