Fix Parcelable Creator logic (deserializer) for List and Parcelable

[eonj]

After some months using this helpful AutoValue Parcel extension, I found that the current implementation is unparcelizing generic-typed fields in an inappropriate way. When a AutoValue declared class type A contains a field typed List<B>, The generated createFromParcel uses readArrayList with ClassLoader of type A -- not B.

I tried to fix this problem in more broad and generous way -- for example, can we fix it with the map? Can we show an informatic message to the user when the type parameter is not a concrete bound but a extends T or a super T? Can we just warn the user instead of blowing javac with an unhandled AutoValueParcelException?

But I failed because I cannot read and change the whole code, so I submit a patch currently used (by my team). Thank you.

[rharter]

This was an intentional change to fix some issues where the generic type can't be used (#108, #109). It was changed in #112.

It looks like this PR is effectively reverting that change and will cause those issues to regress.

[eonj]

@rharter Thank you, I read #112 changes and got it: you're right this PR is not sufficiently caring about the type wildcard or extends/super type bounds (as I said above). I'm glad to know that this kindof problem is already known, and also good to know why the UT's were also expecting the wrong type parameters.

My question is: do you have any plans for make right generic support again for the possible cases; or can you give me any instructions for alternative solution for correct generation?