RequirementMachine: Protocol typealias support

[slavapestov]

While you could already reference protocol typealiases from contexts where type resolution is downstream of generic signature minimization, referencing protocol typealiases from where clauses is special because those protocol typealises must participate in the rewrite system.

The way this works is that a protocol typealias introduces a rewrite rule:

• If the underlying type of the typealias is another type parameter, the rule takes the form [P].A => X where P is the protocol, A is the name of the typealias and X is the type term for the underlying type.
• If the underlying type is concrete, the rule takes the form [P].A.[concrete: C] => [P].A, where C is the concrete type.

Indeed, a protocol typealias looks like a lot like an associated type together with a single same-type requirement, with the major difference being that no associated type symbol is introduced. Since a protocol typealias is not canonical -- we always want to replace it with its underlying type -- the reduction order must be tweaked.

Previously a shortlex order was used, where terms were first compared for length, and then two terms with the same length were compared pairwise. To ensure that typealises are always canonicalized away, the order will now first compare the number of name symbols on both sides; a term with more name symbols always orders after a term with fewer name symbols, even if it is shorter.

The GenericSignatureBuilder would perform name lookups into protocols to resolve typealiases as needed. The RequirementMachine builds the rewrite system in one shot, so it would need to page in all members of every deserialized protocol to find typealiases. Instead, we extend the protocol requirement signature to use a new RequirementSignature type that stores typealias information in addition to the ArrayRef<Requirement> that was stored before. This new representation round-trips through serialization.

Another change here is only protocol typealiases defined in the protocol itself participate in the rewrite system. Typealiases in protocol extensions can still be referenced from contexts downstream of generic signature minimization, but they cannot be referenced from where clauses with the Requirement Machine.

Protocol typealias rewrite rules participate in minimization but are tracked separately from "ordinary" requirements.

One funny quirk is that the rule introduced for a protocol typealias is indistinguishable from a where clause referencing an invalid associated type:

protocol P1 where X == Y.Z {
  associatedtype Y : P2
}

protocol P2 {
  associatedtype Z
}

However, this "invalid where clause" spelling will be diagnosed after the generic signature is built when we perform the second pass over the where clause, so this isn't a backdoor to spelling a typealias in a new way.

Fixes rdar://problem/88134748.

[slavapestov]

@swift-ci Please smoke test

[slavapestov]

@swift-ci Please test source compatibility

[slavapestov]

@swift-ci Please smoke test