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>
Read installed package info file as UTF-8

Currently installed package info file is written in UTF-8. So UTF-8
should be used explicitly or it can cause "invalid byte sequence"
error if system encoding is incompatible to UTF-8.
Merge pull request #2007 from ezyang/ezyang-process-version

Weaken dependency on process.
Merge pull request #2006 from saturday06/read_installed_package_config_as_utf8

Read installed package info file as UTF-8
D.Compat.CreatePipe: use locale encoding

Issue #1895. `createPipe` opened handles in binary mode by default,
which mangles text encoded for the current locale. Now, `hSetEncoding`
is called on the new handles. This requires `base >= 4.2`.
Unit test to check locale of handles created with `createPipe`
Merge pull request #2011 from ttuegel/create-pipe-encoding

D.Compat.CreatePipe: use locale encoding
Merge pull request #1991 from ezyang/master

Implement "reexported-modules" field, towards fixing GHC bug #8407. (ROUND 2)
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; otherwise, we fallback to package keys ==
package IDs.

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.

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