Package keys (for linking/type equality) separated from package IDs.

This patch set makes us no longer assume that a package key is a human
readable string, leaving Cabal free to "do whatever it wants" to allocate
keys; we'll look up the PackageId in the database to display to the user.
This also means we have a new level of qualifier decisions to make at the
package level, and rewriting some Safe Haskell error reporting code to DTRT.

Additionally, we adjust the build system to use a new ghc-cabal output
Make variable PACKAGE_KEY to determine library names and other things,
rather than concatenating PACKAGE/VERSION as before.

Adds a new `-this-package-key` flag to subsume the old, erroneously named
`-package-name` flag, and `-package-key` to select packages by package key.

RFC: The md5 hashes are pretty tough on the eye, as far as the file
system is concerned :(

ToDo: safePkg01 test is failing, but for a stupid reason: package deps now
line-wrap past the end, so the grep is not pulling everything.  So, we could
'make accept' the output, but it wouldn't be right!

ToDo: In a later commit, update all submodules to stop using -package-name
and use -this-package-key.  For now, we don't do it to avoid submodule
explosion.

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

Test Plan: validate

Reviewers: simonpj, simonmar, hvr, austin

Subscribers: simonmar, relrod, carter

Differential Revision: https://phabricator.haskell.org/D80
Disable ghc-pkg accepting multiple package IDs (differing package keys) for now.

Duncan requested that ghc-pkg not accept duplicate package IDs (foo-0.1)
by default until the higher level tools can accommodate it.  Until then
you'll need to use the --multi-instance flag to install multiple copies in
the package database.

I think reusing the --multi-instance flag is dodgy, because that can be used
to cause duplicate package keys; but there is a mode of use of the database
where package keys are unique.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Make PackageState an abstract type.

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

Test Plan: validate

Reviewers: simonpj, simonmar, hvr, austin

Subscribers: simonmar, relrod, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D107
Refactor package state, also fixing a module reexport bug.

Instead of building a multiply indirected data structure and querying
it on every import, we now have two data structures moduleToPkgConf
and moduleToPkgConfAll.  moduleToPkgConf is a single-level UniqFM that
is intended to be used for most valid imports; however, it does not
contain any information useful for error reporting.  If an error is
occurred, we then query moduleToPkgConfAll, which contains a more
comprehensive view of the package database.  This field is lazily
initialized (so this means we're retaining the package database list,
but this should be fine because we're already maintaining the entries
of the list.)  Additionally, the full view doesn't keep track of a boolean
toggle for visibility/exposure anymore, but instead tracks the *provenance*
of how the module binding came to be (the ModuleOrigin data type).

Additionally, we move the logic for determining if a module is exposed
or not from Finder.lhs and put it in Packages.lhs; this information is
communicated via the LookupResult data type.  Unfortunately, we can't
directly return a FindResult, because this data type is defined in
HscTypes which depends on Packages.  This is going to change some more
in the near future when I add thinning/renaming to package flags; the
error messages will need to be more flexible.

I've also slightly changed the semantics of error messages for package
qualified imports.  Previously, if we didn't find any package qualified
imports, but there were hidden modules in a *different* package, the error
message would prefer mentioning those as opposed to providing suggestions.
Now, if a module is hidden but in the wrong package, we won't mention it;
instead, it will get mentioned with the other module suggestions.  I
was too lazy to write a test, but I can add one if people would like.

The module reexport bug was, package q reexported p:P as Conflict,
and package r reexported p:P2 as Conflict, this was *not* reported as
a conflict, because the old logic incorrectly decided that P and P2 were
the same module on account of being from the same package.  The logic here
has been corrected.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Refactor PackageFlags so that ExposePackage is a single constructor.

You can parametrize over the different selection by using a
different PackageArg.  This helps reduce code duplication.

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