Previously, the GHC ecosystem assumed that for any package ID (foo-0.1), there
would only be one instance of it in the installed packages database.  This
posed problems for situations where you want a package compiled twice against
different sets of dependencies: they could not both exist in the package
database.

Package keys are a hash of the package ID and package
dependencies, which identify a package more uniquely than a package ID, but less
uniquely than an installed package ID. Unlike installed package IDs, these can
be computed immediately after dependency resolution, rather than after
compilation.  Package keys require support from the compiler.  At the moment,
only GHC 7.10 supports package keys (the reason is that old versions of GHC
do a sannity check to see that the <pkg-name>-<pkg-version> stored in the
package database matches with the -package-name embedded in an hi file; so
the format is fixed.) We fallback to package keys == package IDs for old
versions.

Note: the ./Setup configure fallback script does not try particularly hard to
pick consistent sets of dependencies.  If your package database is too difficult
for it to resolve, manually provide installed package IDs or use cabal-install's
dependency solver.

Note: This patch *suspends* the reinstall check unless it would result in
a different package, so cabal-install will now happily reinstall foo-0.1
compiled against bar-0.2 if foo-0.1 already exists.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>