Start detangling archetypes from the interface of generic functions.

This breaks the type-canonicalization link between a generic parameter
type and the archetype to which it maps. Generic type parameter types
are now separate entities (that can eventually be canonicalized) from
archetypes (rather than just being sugar).

Most of the front end still traffics in archetypes. As a step away
from this, allow us to type-check the generic parameter list's types
prior to wiring the generic type parameter declarations to archetypes,
using the new "dependent" member type to describe assocaited
types. The archetype builder understands dependent member types and
uses them to map down to associated types when building archetypes.

Once we have assigned archetypes, we revert the dependent identifier
types within the generic parameter list to an un-type-checked state
and do the type checking again in the presence of archetypes, so that
nothing beyond the generic-parameter-list checking code has to deal
with dependent types. We'll creep support out to other dependent types
elsewhere over time.



Swift SVN r7462

lib/Serialization/ModuleFormat.h

@@ -244,6 +244,7 @@ namespace decls_block {
     NAME_ALIAS_TYPE = 1,
     GENERIC_TYPE_PARAM_TYPE,
     ASSOCIATED_TYPE_TYPE,
+    DEPENDENT_MEMBER_TYPE,
     NOMINAL_TYPE,
     PAREN_TYPE,
     TUPLE_TYPE,
@@ -322,6 +323,11 @@ namespace decls_block {
     DeclIDField // associated type decl
   >;
 
+  using DependentMemberTypeLayout = BCRecordLayout<
+    DEPENDENT_MEMBER_TYPE,
+    TypeIDField,      // base type
+    IdentifierIDField // member name
+  >;
   using NominalTypeLayout = BCRecordLayout<
     NOMINAL_TYPE,
     DeclIDField, // decl