We were checking that the witness is at least as available as
the intersection of the protocol and the conforming type.
In the case where the conformance is defined in an extension,
this should actually be the intersection of the protocol and
the _availability of the extension_.
Fixes <rdar://problem/74114880>.
This replaces the old exportability check with a call into the
new general conformance availability check entry point.
Part of <rdar://problem/35158274>.
If a conformance is defined in an extension, we now look for
references to the conformance in types and expressions and
respect's the extension's availability (or deprecation, etc).
The conformance checker itself still needs to check conformance
availability of associated conformances and the like; that will
be a separate change.
Note that conformances defined on types don't require any
special handling, since they are as available as the
intersection of the conforming type and the protocol.
By default, we diagnose conformance availability violations
where the OS version is not sufficiently new as warnings, to
avoid breaking source compatibility. Stricter behavior where
these violations are diagnosed as errors is enabled by passing
the -enable-conformance-availability-errors flag. There are
test cases that run both with and without this flag. In the
future, we hope to make the stricter behavior the default,
since after all, violations here can result in link errors and
runtime crashes.
Uses of completely unavailable conformances are still always
diagnosed as errors, even when this flag is not passed in.
Progress on <rdar://problem/35158274>.
