Deserialize generic contexts by mapping their archetypes

to the archetypes of their generic parameter declarations.

This was a major inconsistency that was causing a lot of
problems with deserialized generic functions in the presence
of chained module files.  In particular, what would happen is
that all the deserialized uses of the archetype would be
mapped to a freshly-created archetype, but the GenericParamList
would refer to GenericTypeParamDecls deserialized from
(potentially) a different ModuleFile and therefore using a
different archetype (since the deserializer assumes that
different modules never share archetypes).

The fix relies on processing a generic parameter list before
any references to the archetypes.  Unfortunately, we have
bogus references to archetypes in substitution lists scattered
everywhere in SIL and the AST.  I've introduced a really
gross hack where we allow archetypes to be created in that
way but just drop them (in favor of the parameter's archetype)
after processing the generic parameter list; this should
work as long as all the decontextualized references are
basically pointless, but like I said, it's gross, and I've
filed rdar://16240384 to clean it up.

Swift SVN r14694

include/swift/Serialization/ModuleFile.h

@@ -133,6 +133,10 @@ public:
       Value = deserialized;
       return *this;
     }
+
+    void unsafeOverwrite(T t) {
+      Value = t;
+    }
   };
 
   /// A class for holding a value that can be partially deserialized.