In other words, give it a callback, changing the type from

    globalRepos :: GlobalFlags -> [Repo]

to

    Verbosity -> GlobalFlags -> ([Repo] -> IO a) -> IO a

This will be necessary for repositories that need to do some
repository-specific initialization (even if we don't currently have any, we
will soon). The Verbosity flag is not used yet, but will be.

This just changes the type and deals with the fallout.

The old Repo type has a repoKind

    repoKind     :: Either RemoteRepo LocalRepo,

where LocalRepo was isomorphic to unit:

    data LocalRepo = LocalRepo

This commit changes Repo to

    data Repo =
        -- | Local repositories
        RepoLocal {
            repoLocalDir :: FilePath
          }

        -- | Standard (unsecured) remote repositores
      | RepoRemote {
            repoRemote   :: RemoteRepo
          , repoLocalDir :: FilePath
          }

instead, which is a little more idiomatic and will make adding more repository
types easier.

Right now this just wraps the list of cache entries, but this might make it
easier in the future to change the structure of the cache.

In particular, distinguish between the repo-global index and a (sandbox-)local
index.

GHC 8.0 changed the `ErrorCall` type to have an extended constructor,
and backward compatibility has been provided via PatternSynonyms:

    data ErrorCall = ErrorCallWithLocation String String
        deriving (Eq, Ord)

    pattern ErrorCall :: String -> ErrorCall
    pattern ErrorCall err <- ErrorCallWithLocation err _ where
            ErrorCall err  = ErrorCallWithLocation err ""

However, due to https://ghc.haskell.org/ticket/8779 the
exhaustive-checker doesn't cope well with pattern-synonyms yet, and so
we get a non-exhaustive pattern-match failure when matching on
'ErrorCall' now.

As the matching on the constructor 'ErrorCall' is done here to help
infer the Exception instance, we can also just annotate the type
directly, and eschew the problematic pattern match.

While at it, this commit also makes this module CPP-free.

Cabal lib for nix local build

Extend repo config with security settings

Remove magic value from `globalCommand`

About the ghc package dbs in particular.

For supporting multi instance registrations on older GHC versions.

This extends `RemoteRepo` with new fields

``` haskell
-- | Enable secure access to Hackage?
remoteRepoSecure :: Bool,

-- | Root key IDs (for bootstrapping)
remoteRepoRootKeys :: [String],

-- | Threshold for verification during bootstrapping
remoteRepoKeyThreshold :: Int,
```

and modifies the parser accordingly. This does not yet require a dependency on
the security library.

NOTE: We suggest to make the security functionality opt-in, rather than
opt-out, for the first official release. Thus, the 'secure' field will be set
to 'False' when initializing a `~/.cabal/config` file, and existing
`~/.cabal/config` files will be interpreted as if they had `secure: False`.

In the definition of `globalCommand` we had

    (case showOrParseArgs of ShowArgs -> take 8; ParseArgs -> id) [..]

the intention here is that the first 8 options will be shown when the user asks
for `--help`, and the rest are not. However, this is rather error prone. If we
forget to update that value when adding a new command line argument, we might
either be wondering why the option isn't showing in the help text,
or--worse--push another flag out of the help text without noticing.

This commit changes this to

    args ShowArgs  = argsShown
    args ParseArgs = argsShown ++ argsNotShown

    argsShown    = [..]
    argsNotShown = [..]

which is a lot more robust.

For some reason my cpp does not fail with #if THING_NOT_DEFINED
but the travis one does, so use #ifdef instead.

The ProgramDb Binary instance is a bit odd by leaving out the Programs,
only including the ConfiguredPrograms. Of course this is because the
Programs contain functions. But the ProgramSearchPath is concrete and
should be included.

This is to allow monitoring programs for changes. The combination of the
location where the program was found, and all the other locations where
the program was looked for gives the full set of files to monitor for
changes in that program.

The Program programFindLocation method is extended to return the
locations looked at but where the prog was not found. The default
implementation of programFindLocation, findProgramOnSearchPath, is
extended to return those locations.

Other places have to change, mostly just the type. In a couple places in
GHC & GHCJS where there is additional searching done, the not-found
locations have to be collected and returned.

But in this patch, don't actually return them yet, so not yet changing
the resturn type.

The purpose here is change monitoring. In cabal-install we want to be
able to automatically re-run various actions when the build environment
changes, including when programs have changed (e.g. due to a $PATH
change, finding the compiler in a different location). The basic
information required for such change monitoring is not only the location
where a program was ultimately found, but all the locations where it was
looked for and not found. Otherwise one will miss the case where having
previously found the program in one location, later on the program
appears earlier in the search path. In this case a build system should
notice and react, but if it only monitors the ultimate location where
the program was found then this is impossible. The build system also
needs to monitor the locations where the program was not found, to make
sure it is still not there. This principle actually applies anytime we
have a file search (e.g. hs-source-dirs), programs are just one example.

The findProgramOnSearchPath function is what we use in most places to
implement the Program abstraction's programFindLocation method.
Re-export it via Program module.

The only place that was still using the old findProgramLocation
instead was in HaskellSuite. Deprecate findProgramLocation which
is now no longer used.

This is in preparation for changing the return type of
findProgramOnSearchPath.

It provides a way to find out what files need to be monitored to detect
changes in a compiler's package database.

This is not used within the Cabal lib.

With support for GHC and GHCJS. All Cabal lib internal uses remain
traditional single instance, so there's no change of behaviour.

This supports the feature of newer ghc-pkg version which have the
register --enable-multi-instance flag. This allows registering multiple
instances of the same version of a package into a single database.

In addition, to support the same feature on some older ghc-pkg versions,
the HcPkgInfo has a recacheMultiInstance capability, which tells us if
the trick of registering multiple instances by running ghc-pkg recache
works. This is known to work for all versions of ghc-pkg that support
the recache command at all.

Then HcPkg.registerMultiInstance will use one of the two methods
depending on which is supported, or fail if neither is. Currently only
registering into specific package dbs is supported, not global or user.

This new multi-instance feature is needed for cabal-install.

Invocation support but not used yet.

Part 1: just add the fields and fill them in for each HcPkg user.

Prior to further extension. Just share the common args calculation.

And fix up the db path for UHC. UHC cannot just register anywhere, like
compilers that have a hc-pkg can. It has to be special locations. Now
that registerPackage no longer takes the inplace :: Bool arg, UHC's impl
of registerPackage has to get the dir from the PackageDbStack without
knowing if it's implace or not. So the correct inplace location has to
be set earlier for the inplace package db, which is what this does.

Add doesPackageDBExist and deletePackageDB, and export the new
createPackageDB. This gives a more complete compiler-independent API for
package db manipulation.

The HcPkgInfo useSingleFileDb is split into two: supportsDirDbs and
requiresDirDbs. Then rather than HcPkg.init callers having to do the
writeFile [] thing, HcPkg.init does it itself automatically based on the
HcPkgInfo. In the case that supportsDirDbs is True but requiresDirDbs is
False then we have a choice, to use dir style or file style. For
compatability reasons, when using ghc/ghc-pkg for the inplace package db
we want to use the old file style, even though dir style is supported.
However in other circumstances (e.g. in places in cabal-install) we
would like to use the dir style if it's supported, and there are no
backwards compat issues. So HcPkg.init gains a new Bool arg to request
using the file style if it's still supported. Only this mode is used
within Cabal itself, but the non-compat mode is available for other
users.

The compiler-independent initPackageDB is left with the same old
behaviour, but a new createPackageDB has the extra compat argument
(which is only passed to hc-pkg for ghc-pkg).

Drop the now-unused PackageDescription and inplace :: Bool args. And
instead of taking the whole LocalBuildInfo, just take the bits we need:
the compiler and program db. The package db stack was already passed in
separately. Also reorder args to follow standard conventions.

Rather, pass the individual bits we need, which is the program db
and in some cases the compiler. This is a step towards having the main
registerPackage not take the LocalBuildInfo. That is useful in contexts
like cabal-install where we do not have a full LocalBuildInfo, but we
still want to be able to register packages in a compiler-agnostic way.

The main reason is to stop using the pkg and inplace args so that we
can drop them entirely. A side benefit is that we don't actually want
to emit a setupMessage for inplace registering, since that's a rather
uninteresting internal action. We only want it for the explicit
register command. So only one caller gains a call to setupMessage.

Remove the now-unused PackageDescription and inplace :: Bool args.

Not yet changed the compiler-independent registerPackage.

UHC's version of registerPackage is the only one that makes use of the
PackageDescription and inplace :: Bool args, and it's quite wrong for
doing so. Registering a package should depend on the content of the
InstalledPackageInfo and the PackageDBStack to register into and the
Compiler to register with. It should not depend on the original source
PackageDescription, and should not need a separate inplace arg. The
location is determined by the PackageDBStack. UHC was not following
this pattern and thereby forcing the general compiler independent
registerPackage to take annoying and unnecessary arguments.

With this patch, the register location is determined by the
PackageDBStack. The source package id also comes from the
InstalledPackageInfo rather than the source PackageDescription.

This patch does not yet change the registerPackage type.

It's used three times already. This isn't important on it's own, but
simplifies subsequent changes, when we add yet another use of it.

To be used in cabal-install. Also use it in one place in Cabal.

Most types have these already. This just adds a few more.

This is needed in order to be able to update GHC HEAD to
use binary-0.8 as planned for GHC 8.0

/cc @kolmodin