Bench.hs: use exitSuccess and forM

Solver: limit where package target constraints apply

When we have a target like "foo-1.0", in terms of solver input this
gets turned into a target package name of "foo" and a (labelled)
constraint of "foo == 1.0". This constraint is of course to ensure
that we pick the right target. However, with the recent addition of
qualified package goals we have the possibility of picking multiple
versions of the same package (e.g. via setup deps). If we have a
constraint like "foo == 1.0" apply everywhere then it becomes
impossible to pick multiple versions of package "foo", which may
mean we cannot find a solution at all. But the constraint for the
target need not apply everywhere, it's just to ensure that for the
"main" instance, we pick the right version.

This patch makes that precise. We have these constraints arising
from targets apply only to package name goals that are suitably
unqualified: qualifications arising from independent goals and from
base version trickery are ok, but qualifiactions from setup deps
are not. Or to put it another way, these target constraints do not
apply to goals arising as the result of setup dependencies.

As a more concrete example, this allows a situation where a package
needs an old version of Cabal as a setup dep, but a new version of
Cabal is also present in the main part of the solution as a normal
library dep. Whenever we solve for that main Cabal lib as a target
it would previously fail (it would be impossible to satisfy the
conflicting constraints on the Cabal setup dep) and it now works.

The only change between process 1.3 and 1.4 is:

"Added child_user and child_group to CreateProcess for unix. #45"

And the relevant code in Cabal doesn't seem affected by those additional
members.

	Bump lower bounds of dependencies 

https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries/VersionHistory

CPP-reducing refactoring

This refactoring allows to drop `{-# LANGUAGE CPP #-}` from a couple of
modules again.

cabal-install Upload.hs flip mapM_ -> forM_

why DeriveGeneric is there?

Check.hs catMaybes . map -> mapMaybe

ReadP.hs : use >=> and replicateM from Control.Monad

Configuration.hs: catMaybes . map -> mapMaybe

CopyFile.hs: use withBinaryFile instead of bracket

TempFile.hs: concat imports

Set Build-type: Custom

as there now is custom code is Setup.hs

Manual page generation

Refactoring and two Doc/Wording changes

Simplify a few InstallPlan utils, and use setup deps in a few places

When setup deps were introduced "Add ComponentSetup to ComponentDeps", we
kept all uses to be the same old deps, without changing anything by using
those new setup deps. In several places in InstallPlan it makes sense to
use all deps, including setup deps. In fact for InstallPlan we should always
use all deps except in one place: in checking plan validity where we check
for dependency inconsistencies. That's the one place where we look only at
"normal" non-setup deps to check that we're using only one version of each
package.

So for example, with this patch the freeze command now includes setup deps
in the frozen set. The other case that should change is that failures of
deps of packages used only for setup scripts should now be handled properly
because we will look at setup dep edges when looking for things that depend
on a failed package.

Simpler, simpler versions now exist in the InstallPlan module. Those
ones are simpler because they can use the cached Graph.

These are also easy to implement based on the Graph in the InstallPlan.

Not currently used, but will be eventually.