Add some tests of our Haddock support

(cherry picked from commit 5bcb6f7601a97b274cff868d8090437a717301cc)
Bring a Haddock version check in line with message

(cherry picked from commit a718eb073eb871a1f573561ce3bbb04ada885043)
Remove support for Haddock versions < 2.0

Dropping this support is unlikely to be a problem in practice.  Debian
oldstable is currently on version 2.6.0 of Haddock, for example.

This change enables future code simplification.  Currently we
preprocess both Haskell files requiring the CPP and Literate Haskell
files; newer versions of Haddock can handle these natively.

Fixes issue #1718.

(cherry picked from commit 98c537f1263a1e46786d9abba55301768ca12fe5)
Use Haddock's builtin support for .lhs and CPP

This is a code simplification on our end.

Thanks to Mikhail Glushenkov for the suggestion.

(cherry picked from commit 5729bc5c175a3b6863e5533915d9e9ff8e45a600)
Fix: "cabal haddock" uses CPP overzealously

Until recently we supported ancient versions of Haddock, pre v2.0.  To
support the CPP extension with such versions, cabal had to invoke the
CPP before invoking Haddock on the output.  For simplicity cabal would
invoke the CPP on all Haskell files, if any Haskell file required CPP.
However, invoking CPP on a file which does not require it can cause
build failures.

Haddock v2.0+ supports the CPP via GHC, and even automatically
preprocesses any file with the {-# LANGUAGE CPP #-} pragma. Hence we
simply need only tell Haddock to enable the CPP when the CPP is a
package level default extension.

Fixes issue #1808.

(cherry picked from commit ba4ae3d08bd9a9c3cd0453526b7763cad5524ee6)
Bump Cabal version number to 1.20.0.2