Use extra-prog-path in running build-type configure

Add warning about testing Cabal on Windows

Prevent detailed-0.9 test suites from freezing on Windows (fixes #2762)

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

For a while now, we lift out dependencies from conditionals.  If a
package is dependended on regardless of the outcome of a test, the
dependency is lifted out. This has the advantage that we can choose an
instance for the package prior to choosing the value of the flag. Often,
this is the desired behaviour for flags, i.e., to have the flag choice
implied by the possible package choices, rather than the other way
around.

Prior to this change, lifting was simply adding an unconstrained
dependency to such a package at a higher level, which would then of
course still be refined after making the flag choice. We are now making
this more precise by actually computing the union of the ranges in both
branches of the conditional. So we will not choose an instance on the
top level that will later be rejected by both branches.

Add DeriveLift to Language.Haskell.Extension

Add hasUpperBound and hasLowerBound

This is useful for performing PVP bounds checking, especially for
tooling that wants to automate such dependency bounds. A demonstration
of this being used in practice is the --pvp-bounds flag for stack:

https://github.com/commercialhaskell/stack/commit/c774f9905b3b112f58fc3789dfb9c26389d33b24

Lower memory usage during index file parsing #2396

The parsePackageIndex wasn't streaming because resulting list was
hidden in two constructors: Either and tuple. By removing that error
semantics changed in updatePackageIndexCacheFile.

The updatePackageIndexCacheFile problem was sequence call that evaluated
whole list made by parsePackageIndex. By using lazySequence any error
during index file parsing will be raised during writing to cache file.

Also removed reacPackageIndexFile, as it wasn't used anywhere as far as
I can tell. If this is a mistake I'll include it again.

Revert "Exit with an error if $CABAL_SANDBOX_CONFIG does not point to extant file"

Call addInfoForKnownRepos in initialSavedConfig

We called addInfoForKnownRepos when _parsing_ a file, but not when creating the
initial file. This meant that when we created an initial file, we would end up
with a different internal configuration (which would not have
addInfoForKnownRepos applied) than if we wrote out and then read back that same
initial file (which would).

This reverts commit 3488f593.

Bump the upper bound on 'process'.

Extend other-extensions documentation

Change "XXX" markers to "TODO"

Don't print ExitCode in topHandlerWith

Closes #2807.

Fixes #2805.

Add Bash script for starting development

use a liberal import of Control.Exception to grab the new ErrorCall pattern in base

Use the sandbox config for "cabal get"

If I try to use a local cabal-install repo cache by adding a
"remote-repo-cache: <dir>" setting to the local cabal.config, this is
respected by "cabal update" but then ignored by "cabal get", which seems
wrong.  This respects the local cabal.config in "cabal get" too.  Maybe
all commands should do this?