If the first type has a code completion token, don't record a same type constraint because otherwise if we have
```swift
K.#^COMPLETE^# == Foo
```
we parse this as
```
K == Foo
```
and thus simplify `K` to `Foo`. But we didn't want to state that `K` is `Foo` but that `K` has a member of type `Foo`.
rdar://77458518
The logic here had diverged from UnqualifiedLookup. One day we'll merge
the two, for now clean it up a bit to match.
Note that all generic parameters now have 'Reason' reported as 'Local'.
I don't believe this really matters.
Fixes <rdar://problem/20530021>.
Semantically, these are not superclass/refined-protocol members.
If I have a generic parameter <T : P & Q>, then when looking at
a value of type T, members of P and Q are at the same "level" as
if I had a value of type (P & Q).
We actually want to not use types at all here and instead refactor
this code to use the various decl-level requests instead... but for
now lets be consistent between typo corrections inside function
and type context.
This gets us to the point where we will complete 'T' here:
associatedtype T where #^A^#
And when completing here, we now at least find the correct declaration:
associatedtype T: P where T.#^A^#
There is a remaining issue that in the second example we will not find
members of `P`; we seem to be missing the conformance from the archetype
we get for `T`.
rdar://problem/20582394
Complete generic parameters and their members inside generic where
clauses on structs, classes, enums, extensions, typealiases, funcs,
subscripts and inits.
Still not handled correctly are associatedtypes.
rdar://problem/20582394
