Split the cabal_macros.h generation into a helper and wrapper

Makes it easier to reuse this code in other contexts, for example if we
want to build without a .cabal file using all the packages in the
environment.
Add a list command to the HcPkg module

Only useful for getting the source package ids. Does not get the
installed package ids or any other details. Most use cases should
still use dump.
Revert "Try harder to pick the correct version in cabalLibVersionToUse."

This reverts commit a17491d70741d28d9b6037640e6fb2b041fc81bc.

That commit made the logic much more convoluted and broke the following use case
(for sandboxed packages with build-type Custom):

$ cabal configure -w /path/to/ghc
$ cabal build
Merge pull request #1399 from dcoutts/cabal_macros.h-util

Split the cabal_macros.h generation into a helper and wrapper
Merge pull request #1400 from dcoutts/hc-pkg-list

Add a list command to the HcPkg module
Make absolute haddock paths proper URLs

Fixes #1064, #1406
Merge pull request #1407 from feuerbach/haddock-urls

Make absolute haddock paths proper URLs
Initial implementation of repl command

No support yet for ovreriding the ghci :reload command.
No support in build or repl for module/file targets.
Not yet tested with sandboxes.
Merge pull request #1404 from dcoutts/repl

Initial implementation of repl command
Flesh out the Program run code to cover all cases

Previously the runProgramInvocation impl only covered the common special
cases that we currently use. In particular it did not support env vars
or changing the workind directory.

Also change the ProgramInvocation { progInvokeEnv } to allow unsetting
env vars, not just setting them to new values.

This stuff would be better if we could use createProcess for all cases
but that doesn't yet support running programs in the foreground with
proper ctl-C handling (only rawSystem currently supports that).
Add a programOverrideEnv to the ConfiguredProgram

And use it in programInvocation. So configured programs can have
environment var overrides that will be used in all invocations, like
the existing support for default and override arguments.
Allow the Program programPostConf to update all settings, including env

So rather than only returning the default args it can adjust any of the
ConfiguredProgram settings, including programDefaultArgs as now but now
also the programOverrideArgs and the new programOverrideEnv.
Add a notion of program search path to the ProgramDb

Previously we would just use the normal system $PATH for finding
programs (unless the Program provided some custom method). Now the
ProgramDb has its own notion of the search path and we use that for
finding programs (by default). The search path can be either specific
directories or the system search method (ie $PATH on unix and something
similar on Win32). The default search path is just the system one.

In addition, this search path is passed on to programs when we invoke
them as the $PATH env var.
Take the opportunity to simplify the ghc tool configuration

When we configure ghc we have to find a bunch of related tools (like gcc
on windows). We do that by looking in some extra locations first, and
that's now simpler to do with the new infrastructure by just tacking an
extra directory on the front of the search path.
Add a configure --extra-prog-path flag

Can be used to add extra dirs to the end of the program search path.
This in mainly useful as a config file entry rather than a command line
flag, but it'll exists as both.
Use the --extra-prog-path flag in cabal-install

We have to pass it properly in the setupWrapper. For the external build
method we just set the $PATH rather than passing the flag. This way it
works when talking to Setup.hs built with an older Cabal lib.
Add a sensible extra-prog-path to the default ~/.cabal/config

e.g. extra-prog-path: /home/duncan/.cabal/bin

This should help with the problem that people install tools like alex,
happy, c2hs etc and then cabal cannot find them.

Arguably we should have this as the default value for extra-prog-path,
so that it affects existing installations, rather than just affecting
new installations where we generate the ~/.cabal/config for the first
time. It's easy to change if we want to do that.
Add some more recent GhcOptions

Add support for:
 -no-hs-main
 -dynamic-too  (now a three-way choice with -static & -dynamic)
 -dynhisuf -dynosuf
 -dyno
All the options we use internally should have their own flags. We should
really only be using ghcOptExtra for things from the user.
For cabal repl, filter out flags that cause warnings

Like -O -threaded -prof -debug etc.
Fix the cabal repl --ghc-option(s) flags