NestedTypeUpdate was mostly just the internal name for
ArchetypeResolutionKind, but the translation was a bit lossy and there
was no point in having separate enums. Standardize on
ArchetypeResolutionKind, adding a new case (WellFormed) to capture the
idea that we can create a new potential archetype only when we know
there is a nested type with that name---and avoid creating unresolved
potential archetypes.

(cherry picked from commit fafeec0)

Rather than abusing the "superclass" requirement source with a null
protocol conformance, introduce a separate "structurally derived"
requirement source kind for structurally-derived requirements that
don't need any additional information, e.g., the class layout
requirement derived from a superclass requirement.

(cherry picked from commit ffea1b3)

Centralize and simplify the handling of conformance requirements
resolved by same-type-to-concrete requirements in a few ways:

* Always store a ProtocolConformanceRef in via-superclass and
  via-concrete requirement sources, so we never lose this information.

* When concretizing a nested type based on its parent, use the
  via-concrete conformance information rather than performing lookup
  again, simplifying this operation considerably and avoiding
  redundant lookups.

* When adding a conformance requirement to a potential archetype that
  is equivalent to a concrete type, attempt to find and record the
  conformance.

Fixes SR-4295 / rdar://problem/31372308.

(cherry picked from commit 52e52b5)

(cherry picked from commit a4e35ed)

…ments for.

(cherry picked from commit b095c8a)

…pes.

In some circumstances, we could end up growing increasingly-nested
potential archetypes due to a poor choice of representatives and
anchors. Address this in two places:

* Always prefer to use the potential archetype with a lower nesting
  depth (== number of nested types) to one with a greater nesting
  depth, so we don't accumulate more nested types onto the
  already-longer potential archetypes, and

* Prefer archetype anchors with a lower nesting depth *except* that we
  always prefer archetype anchors comprised of a sequence of
  associated types (i.e., no concrete type declarations), which is
  important for canonicalization.

Fixes SR-4757 / rdar://problem/31912838, as well as a regression
involving infinitely-recursive potential archetypes caused by the
previous commit.

(cherry picked from commit a72a2bf)

…Formed.

(cherry picked from commit 791ac7f)

…ents.

Ensures that we don't admit invalid cases where the concrete type does
not conform to the required protocol.

(cherry picked from commit c879b95)

When two potential archetypes are merged and only one of them was a
concrete type beforehand, concretize the nested types in the
equivalence class of the non-concrete potential archetype. Otherwise,
we're liable to miss redundancies.

This feels like an ad hoc extension to an ad hoc mechanism, but gets
us back to parity with this patch series.

(cherry picked from commit bf730ff)

(cherry picked from commit b51529f)

When we see two type(aliase)s with the same name in a protocol
hierarchy, make them equal with an implied same-type requirement. This
detects inconstencies in typealiases across different protocols, and
eliminates the need for ad hoc consistency checking. This is a step
toward simplifying away the need for direct-diagnosis operations
involving concrete type mismatches.

While here, warn when we see an associated type with the same as a
typealias from an inherited protocol; in this case, the associated
type is basically useless, because it's going to be equivalent to the
typealias.

(cherry picked from commit c47aea7)

Specifically, we need to be able to add a new potential archetype for
the anchor. This API might need refinement.

(cherry picked from commit aeb5b01)

(cherry picked from commit 2f00a08)

When a concrete requirement is invalid due to the concrete type
lacking a conformance to a particular, required protocol, don't emit
that incorrect requirement---it causes invalid states further down the
line.

Fixes SR-5014 / rdar://problem/32402482.

While here, fix a comment that Huon noticed trailed off into oblivion.

(cherry picked from commit dd38697)

(cherry picked from commit 6862ef1)

…ass.

Fixes one recently-found crasher.

(cherry picked from commit e256a9d)

Fixes two more recently-found GSB crashers.