Helped extra-ghci-libraries find its way to .cabal files.
Switch InstallPlan over to using IPID-indexed PackageIndex.

While this doesn't let us get rid of Distribution.Client.PackageIndex,
it does make InstallPlan more flexible, so we can have the same
package name-package version in the install plan multiple times.
We do this by synthesizing fake installed package IDs to act
as placeholders prior to compilation.

There is some shindig with 'FakeMap' in PackageIndex, check out
the Note in that file for more details.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Accept duplicates when they're all the same.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Add instance Binary LocalBuildInfo
Use Binary instance to save/restore dist/setup-config
Load binary LocalBuildInfo in package-tests

PackageTests has its own version of getPersistBuildConfig which does not
check which version of Cabal created dist/setup-config. Now that the
LocalBuildInfo is written with Binary, this version needed to be
updated, too.
Clarify Cabal dependencies policy

[ci-skip]
Merge pull request #2076 from ttuegel/binary-lbi

Use Binary to save/restore persistent build config
Exec tests no longer fail if there isn't a sandbox

The tests which delete the sandbox, now check for its existence before
deleting it. This prevents erroneous test failures when the tests are first
run or any time that the sandbox has been deleted.
cabal-install tests use locally built cabal

When running the cabal-install tests, we want to run against the locally built
cabal executable, not any other cabal executable which may be installed.

If we are 1) following the advice of building cabal with `cabal build` (as
opposed to installing it into a sandbox with `cabal install`) and 2) not using
a non-default build directory, the locally built cabal will be located at
`dist/build/cabal/cabal`.

By adding the directory `dist/build/cabal` to the program search path we will
pick up any cabal executable there in preference to any other on the $PATH.

For most users, I expect that this will remove any surprises with an
unexpected cabal executable being selected for running the tests. It will be
sufficient to allow the tests to run on Travis.

For users who have been installing cabal into a sandbox, this change could
result in an older cabal executable being selected. It's not clear to me how
to solve this issue or whether anyone will experience this.
Enable cabal-install tests on travis
Merge pull request #2087 from benarmston/improve-cabal-install-tests

Improve cabal install tests
Support the 1.5 release of 'time'.

Fixes #2100.
Improve a debug message.
Merge pull request #2077 from ezyang/ezyang-accept-duplicates

Accept duplicates when they're all the same.
Bash completion for "cabal sandbox" subcommands

Command "cabal sandbox --list-options" doesn't list subcommands of
"cabal sandbox", but "cabal help sandbox" does. It turns out that it is
easy to parse its output using sed and as such can be added to list of
words for completion.
Test executable tests without hpc
Add printRawCommandAndArgsAndEnv
Enable hpc with LocalBuildInfo flag
Enable program coverage for all components