A substitution map might store an abstract conformance even if the
replacement type is an archetype that conforms concretely via a
superclass requirement.
This is because when we build the substitution map, if the archetype
is represented by a type parameter, we don't have enough information
to know if it will conform abstractly or concretely.
Make sure we use the generic environment derived from the
generic signature of the vtable thunk itself, which can now
be different than the generic signature of the derived
method.
This allows vtable thunks that re-abstract generic requirements
to lower all the way through to IRGen.
We recently added some checking to ensure that a method override's
generic signature does not have any generic requirements not
satisfied by the base method.
Loosening requirements in the other direction was allowed, because
it means the derived method can be called on potentially more types
than the base method.
However, if the generic signatures don't match, a thunk must be
emitted. While we correctly determined whether a thunk should be
emitted, the thunk had the wrong generic signature, and therefore
the wrong calling convention, which would cause crashes at runtime.
Fixes <rdar://problem/57429775>.
