GSB: Teach 'derived via concrete' computation about superclass constraints [5.3]

[slavapestov]

Under certain circumstances, introducing a concrete same-type or
superclass constraint can re-introduce conformance constraints
which were previously redundant.

For example, consider this code, which we correctly support today:

protocol P {
  associatedtype T : Q
}

protocol Q {}

class SomeClass<U : Q> {}

struct Outer<T> where T : P {
  func inner<U>(_: U) where T == SomeClass<U>, U : Q {}
}

The constraint T == SomeClass<U> makes the outer constraint
T : P redundant, because SomeClass already conforms to P.
It also introduces an implied same-type constraint U == T.T.

However, whereas T : P together with U == T.T make U : Q
redundant, the introduction of the constraint T == SomeClass<U>
removes'T : P, so we re-introduce an explicit constraint U : Q
in order to get a valid generic signature.

This code path did the right thing for constraints derived via
concrete same-type constraints, but it did not handle superclass
constraints.

As a result, this case was broken:

struct Outer<T> where T : P {
  func inner<U>(_: U) where T : SomeClass<U>, U : Q {}
}

This is the same example as above, except T is related via a
superclass constraint to SomeClass<U>, instead of via a concrete
same-type constraint.

The subtlety here is that we must check if the superclass type
actually conforms to the requirement source's protocol, because it
is possible to have a superclass-constrained generic parameter
where some conformances are abstract. Eg, if SomeClass did not
conform to another protocol P2, we could write

func foo<T, U>(_: T, _: U) where T : SomeClass<U>, T : P2 {}

In this case, T : P2 is an abstract conformance on the type T.

The common case where this would come up in real code is when you
have a class that conforms to a protocol with an associated type,
and one of the protocol requirements was fulfilled by a default in
a protocol extension, eg:

protocol P {
  associatedtype T : Q

  func foo()
}

extension P {
  func foo() {}
}

class ConformsWithDefault<T : Q> : P {}

The above used to crash; now it will type-check correctly.

Fixes rdar://problem/44736411, https://bugs.swift.org/browse/SR-8814.

[slavapestov]

@swift-ci Please test