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>.
