GSB: Start purging the notion of "derived via concrete" requirements

[slavapestov]

The notion of a 'derived via concrete' requirement was meant to handle the following scenario:

protocol P { associatedtype T : P }
class C<T : P> : P
func foo<X, Y>(_: X, _: Y) where X : P, Y : P, X : C<Y> {}

The requirement Y : P is implied by X : P, since X : C<Y> introduces Y == X.T, we have X : P, and T : P in protocol P. Since X : P is in turn implied by X : C<Y>, we would normally consider both X : P and Y : P redundant -- but as soon as we drop X : P, we must keep Y : P, since X : C<Y> by itself does not imply that Y : P. This was captured by saying that Y : P was "derived via (the) concrete" requirement X : C<Y>.

However, the recently-introduced mechanism for rebuilding signatures after dropping redundant conformance requirements subsumes this notion. In the above example, once we drop X : P, we build the signature X : C<Y>, Y : P. The only thing we have to change is that when rebuilding a signature, instead of dropping all redundant requirements (which would also drop Y : P) we only drop those that are directly implied by a superclass or concrete type requirement. X : P is directly implied by X : C<Y>, but Y : P is derived from X : P.

Since rebuilding doesn't yet work for requirement signatures, we can't remove it outright, but we can narrow it down to only occur with a requirement signature. Once we can rebuild requirement signatures, we can remove this logic entirely.

[slavapestov]

@swift-ci Please smoke test

[slavapestov]

@swift-ci Please test

[slavapestov]

@swift-ci Please test source compatibility