This commit addresses the comments in PR #5183.

This uses GHC 7.4 as a reference; i.e. we consider
the versions of boot libraries of GHC 7.4.[12] as the
lower bound we support.

Specifically, w/ GHC 7.4.1, these are the direct dependencies
the cabal solver will come up with (when also forcing
`mtl` to its lower bound):

  array-0.4.0.0
  base-4.5.0.0
  binary-0.5.1.0
  bytestring-0.9.2.1
  containers-0.4.2.1
  deepseq-1.3.0.0
  directory-1.1.0.2
  filepath-1.3.0.0
  ghc-prim-0.2.0.0
  mtl-2.1
  old-time-1.1.0.0
  parsec-3.1.13.0
  pretty-1.1.1.0
  process-1.1.0.1
  text-1.2.3.0
  time-1.4
  transformers-0.3.0.0
  unix-2.5.1.0

(cherry picked from commit 2b73e706)

(cherry picked from commit 80f3e714)

Fix base compat files so they work with GHC < 7.8

Last part of addressing #415 (fwd-ported)

The `setup-custom2` tests implicit `setup-depends` which implies
a `Cabal < 2` upper bound, which is incompatible with GHC 8.2 or later

(cherry picked from commit 8947db49)

(cherry picked from commit 86de9cc9)

As we can't predict the future, we also place a global upper
bound on the lib:Cabal version we know how to interact with:

The upper bound is computed by incrementing the current major
version twice in order to allow for the current version, as
well as the next adjacent major version (one of which will not
be released, as only "even major" versions of Cabal are
released to Hackage or bundled with proper GHC releases).

For instance, if the current version of cabal-install is an odd
development version, e.g.  Cabal-2.1.0.0, then we impose an
upper bound `setup.Cabal < 2.3`; if `cabal-install` is on a
stable/release even version, e.g. Cabal-2.2.1.0, the upper
bound is `setup.Cabal < 2.4`. This gives us enough flexibility
when dealing with development snapshots of Cabal and cabal-install.

This addresses #415

(cherry picked from commit e66106c7)

GHC 8.4.1-rc1 (GHC 8.4.0.20180224) unfortunately still shipped with a
devel snapshot of Cabal-2.1.0.0; but GHC 8.4.1 final will ship w/
lib:Cabal-2.2.0.0

(cherry picked from commit 5066672f)

Fix split-sections flag

Convert `Cabal/changelog` to markdown

the versions are bundled with GHC-8.4.1, no need to support older.

Follow-up to 2a375443

[skip ci]

This will hopefully fix the recent testsuite failures in

 - `PackageTests/TestSuiteTests/ExeV10/cabal-with-hpc.multitest.hs`

due to multiple `transformer` versions clashing

The patch which introduced support for split-sections, 450d6bc4, contained a
cut-and-paste error such that it was controlled by the split-objs flag. Fix
this.

Fixes #5011.

This injects lower-bound constraints on Cabal for custom setup
dependencies to prevent the solver from selecting unsupported
configurations.

Previously we already added an absolute lower bound `Cabal >= 1.20`
for nix-local builds, as that's the minimum version we need to be able
to interact with custom Setup.hs scripts. This refines with logic by
restricting that lower bound even more based on GHC version.

This patch augments this with the following rules:

- GHC 8.4+   constrains  Cabal >= 2.2
- GHC 8.2    constrains  Cabal >= 2.0
- GHC 8.0    constrains  Cabal >= 1.24
- GHC 7.10   constrains  Cabal >= 1.22
- (default   constraint  Cabal >= 1.20)

This only affects nix-style local builds codepaths.

Notational conventions used:

 - `----` separators to group major version series
 - `#` headings to highlight major version bumps,
 - `##` headings for minor version bumps, and
 - `###` headings for patch-levels

Forward-ported from 5339b36e

Addresses #415

bootstrap: Pass SCOPE_OF_INSTALL to ghc when building Setup.hs

Solver cleanup

Add Eta compiler

I think that the code that processes the solver log already evaluates the
conflict sets, but this change should make the code less fragile.

Use 'assertBool' instead of 'assert' to avoid deprecation warning.

tasty-hunit deprecated the Assertable typeclass in version 0.10, so this commit
updates the solver-benchmarks unit tests.