This is a source-level error, not an invariant violation. Instead, plumb
a new hadError() flag, which in the future will assert if no diagnostic
was produced.
The requirements passed to this request may have been substituted,
meaning the subject type might be a concrete type and not a type
parameter.
Also, the right hand side of conformance requirements here might be
a protocol composition.
Desugaring converts these kinds of requirements into "proper"
requirements where the subject type is always a type parameter,
which is what the RuleBuilder expects.
This is a heuristic to ensure that conformance requirements remain in
their original protocol if possible, when the protocol is part of a
connected component consisting of multiple protocols.
This is a refactoring needed to implement 'verify' mode. The
RequirementMachine computes the requirement signature for an
entire connected component of protocols at once, whereas the
GenericSignatureBuilder only does one protocol at a time.
Using the same request for both in 'verify' mode meant that
we would only call the GSB for the first protocol in a
connected component, and then the RequirementMachine would
fill in the rest.
To fix this, split it up into two requests. The original
RequirementSignatureRequest calls into the GSB, and then
kicks off a RequirementSignatureRequestRQM to get the
requirement signature computed by the RequirementMachine
(possibly cached, if this protocol is part of a connected
component with more than one protocol in it).
Now that the 'identity conformance' [P].[P] => [P] is permanent,
we won't see it here, so we can just assume that any non-permanent,
non-redundant rule maps to a requirement.
