Implement "reexported-modules" field, towards fixing GHC bug #8407.

Re-exported modules allow packages to reexport modules from their
dependencies without having to create stub files.  Reexports of the same
original module don't count as ambiguous imports when module finding
occurs.  The syntax is:

    "orig-pkg" OrigName as NewName

You can omit 'as NewName', in which case it is reexported as the same
name.  Self referential aliases work too; however, they're only visible
to packages which depend on this package.

Left to future work: just provide a module name 'OrigName', where ghc-pkg
figures out what the source package is.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Implement package keys, distinguishing packages built with different deps/flags

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, package flags 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>
Add $pkgkey template variable, and use it for install paths.

At the moment, $pkgkey is not supported for build reports, although in
principle we could add support for it, assuming that the configure step
succeeds.

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