Instances of Typeable used to call mkTyCon:

  mkTyCon :: String -> TyCon

which internally kept a table mapping Strings to Ints, so that each
TyCon could be given a unique Int for fast comparison.  This meant the
String has to be unique across all types in the program.  However,
derived instances of typeable used the qualified original
name (e.g. "GHC.Types.Int") which is not necessarily unique, is
non-portable, and exposes implementation details.

The String passed to mkTyCon is returned by

  tyConString :: TyCon -> String

which let the user get at this non-portable representation (also the
Show instance returns this String).

Now we store three Strings in TyCon.  The internal representation is
this:

data TyCon = TyCon {
   tyConHash    :: {-# UNPACK #-} !Fingerprint,
   tyConPackage :: String,
   tyConModule  :: String,
   tyConName    :: String
 }

(internal representations are now provided by Data.Typeable.Internal)

The fields of TyCon are not exposed via the public API.  Together the
three fields tyConPackage, tyConModule and tyConName uniquely identify
a TyCon, and the Fingerprint is a hash of the concatenation of these
three Strings (so no more internal cache to map strings to unique
Ids). tyConString now returns the value of tyConName only, so is
therefore portable (but the String returned does not uniquely
identify the TyCon).

I've measured the performance impact of this change, and performance
seems to be uniformly better.  This should improve things for SYB in
particular.  Also, the size of the code generated for deriving
Typeable is less than half as much as before.

== API changes ==

=== mkTyCon is DEPRECATED ==

mkTyCon is used by some hand-written instances of Typeable.  It still
works as before, but is deprecated in favour of...

=== Add mkTyCon3 ===

  mkTyCon3 :: String -> String -> String -> TyCon

mkTyCon3 takes the package, module, and name of the TyCon respectively.
Most users can just derive Typeable, there's no need to use mkTyCon3.

In due course we can rename mkTyCon3 back to mkTyCon.

=== typeRepKey changed ===

Previously we had

  typeRepKey :: TypeRep -> IO Int

but since we don't assign unique Ints to TypeReps any more, this is
difficult to implement.  Instead we provide an abstract key type which
is an instance of Eq and Ord, and internally is implemented by the
fingerprint:

  data TypeRepKey -- abstract, instance of Eq, Ord
  typeRepKey :: TypeRep -> IO TypeRepKey

typeRepKey is still in the IO monad, because the Ord instance is
implementation-defined.