5.2: Fix heap pollution checks

The ClassCastException that can occur due to heap pollution in an assignment context is specified as follows (5.2):

"The only exceptions that may arise from conversions in an assignment context are ... A ClassCastException if, after the type conversions above have been applied, the resulting value is an object which is not an instance of a subclass or subinterface of the erasure (§4.6) of the type of the variable."

5.3 and 5.5 perform similar checks (although I'm not sure 5.5 currently has an special text to address this).

When an unboxing conversion is applied it doesn't make sense to do this checkcast "after the type conversions"—e.g., you have to convert Object (the erased type of an invocation) to Integer (the compile-time type of the invocation) before you can unbox Integer to int.

Enumerating all the relevant cases for assignment:
- Widening reference: this is a no-op, but at run time a checkcast may need to occur
- Unboxing: may need to checkcast to the boxed type before performing unboxing
- Widening reference + unboxing: Same as unboxing
- Widening reference + unboxing + widening primitive: Same as unboxing

Similar comments apply to invocation contexts and cast contexts.

There also appears to be no specification at all for a checkcast that might be necessary on the receiver of a field access/method invocation.

In addition, I'm not sure users are well-served by how these checks are designed and implemented. It would be more natural to perform checks at the point where a field access or method invocation result has a mismatched type, rather than when that result is stored/used. This would result in slightly more aggressive heap pollution detection. (For example: "List<String> list = ...; Object o = list.get(0);" will never throw CCE, even if the List contains non-Strings. Arguably, users would like it to throw.)