swift234

[Protocol conformance] Refactor protocol conformance representation.

Factor the ProtocolConformance class into a small hierarchy of
protocol conformances: 
  - "normal" conformance, which provides a complete mapping for the
  explicit conformance of a nominal type (which may be generic) to a
  protocol;
  -  "specialized" conformance, which specializes a generic
  conformance by applying a set of substitutions; and
  - "inherited" conformance, which projects the conformance from a
  superclass to a conformance for a subclass.

In this scheme "normal" conformances are fairly heavyweight, because
they provide a complete mapping. Normal conformances are unique,
because they're associated with explicit conformance declarations
(which cannot be repeated within a module; checking is TBD). Thus, IR
generation will eventually emit them as strong symbols.

"Specialized" and "inherited" conformances occur when we're dealing
with generic specializations or subclasses. They project most of their
members through to some underlying conformance, eventually landing at
a "normal" conformance. ASTContext is responsible for uniquing these
conformances when it sees them. The IR generation model for
specialized conformances will involve runtime specialization of the
underlying witness table; inherited conformances are probably no-ops
from the IR generation perspective.

Aside from being the right thing to do, having small, uniqued
conformances for the specialization and inheritance cases is good for
compile-time performance and memory usage. We're not really taking
advantage of this everywhere we could, yet.

This change uncovered a few existing issues (one known, one not
known), particularly because we're projecting inherited conformances
rather than building new conformances:
  - <rdar://problem/14620454>: protocol witnesses to methods of
  classes need to perform dynamic dispatch. See the
  test/Interpreter/typeof.swift test for an example.
  - <rdar://problem/14637688>: comparing NSString and String with ==
  fails, because they are inter-convertible. I suspect we were missing
  some protocol conformances previously, and therefore accepting this
  obviously-invalid code.



Swift SVN r6865