This is going to make adding same-type and superclass requirement
failures might easier, because they only have to supply custom
diagnostic messages and substituted types.
Change logic to traverse the chain of declaration contexts
starting for "affected" declaration's parent and check if the
requirement is satisfied by one of them, if so return it as
requirement's declaration context.
Extract this logic into a method on `RequirementFailure` to make
it accessible for other types of requirement failure diagnostics.
That is, don't look through InOutType anymore, and update callers to
call getInOutObjectType() as well (or not, where it was obvious to me
that InOutType could not appear).
This surfaces more remaining uses of getInOutObjectType() directly.
If generic parameter associated with missing conformance comes
from different context diagnose the problem as "referencing" a
specific declaration from affected type.
Instead of simply pointing out which type had conformance failures,
let's use affected declaration instead, which makes diagnostics much
richer e.g.
```
'List<[S], S.Id>' requires that 'S.Id' conform to 'Hashable'
```
versus
```
initializer 'init(_🆔)' requires that 'E' conform to 'Hashable' [with 'E' = 'S.Id']
```
Since latter message uses information about declaration, it can also
point to it in the source. That makes is much easier to understand when
problem is related to overloaded (function) declarations.
