PackageTests: add full range of TestSuite/Hpc tests

Also runs the HPC tests regardless of the detected version.
Build shared library when linking executables dynamically

Dynamically linking executables will fail without a shared library
unless the executables do not depend on the library or there is no
library. If there is no library, building shared libraries comes at no
cost. If there is a library, the executables usually depend on it, so it
makes sense to --enable-shared.

If the user passes --disable-shared, it will still be honored, but a
warning will be produced.
Enable library profiling when profiling executables

It doesn't make any sense to do a profiling build of an executable if
the library doesn't have a profiled build! The option
--enable-executable-profiling is changed to --enable-profiling to
reflect that it is now a global flag. The old option is still recognized
(for now).
hpc: separate module interfaces by compilation way
PackageTests: set dist prefix

Some package tests run multiple tests on the same package, causing the
build directory to be overwritten. For debugging, it is important to
keep the build directory contents, so in this case we run each test
with a different build directory.
Document --enable-coverage
Bump version numbers to 1.22.0.0
Bump dependency on Cabal to 1.22.0.0
cabal install can be used inside a cabal exec environment

Inside a cabal exec environment cabal should be configured to always use the
correct environment. When there is a sandbox this is addressed by setting the
CABAL_SANDBOX_CONFIG environment variable.

However GHC is configured to use the correct package database through setting
the GHC_PACKAGE_PATH environment variable to include the sandbox database. The
Cabal library previously refused to operate when GHC_PACKAGE_PATH is set in
order to avoid having a different view of the package databases to GHC.

In the case of a cabal exec environment being loaded for a cabal sandbox, it
is safe to allow the use of GHC_PACKAGE_PATH as it is being used to ensure
that GHC uses the same package database as cabal does.

A check is made that GHC_PACKAGE_PATH matches the value that cabal exec set it
to. If it does use of GHC through cabal is permitted.

Fixes #1800
PackageTests.TestSuiteExeV10: make HPC tests conditional on HPC version
Merge pull request #2286 from ttuegel/hpc

Fix compilation ways
Remove duplicate network and network-uri constraint
Merge branch 'master' of github.com:haskell/cabal
Always setup (DY)LD_LIBRARY_PATH for testsuite

Now that Cabal is in charge of RPATH handling on certain OS',
we must always setup a correct (DY)LD_LIBRARY_PATH when
running the testsuite. Not just when we are building relocatable
packages.

The "problem" is, is that Cabal now adds an RPATH pointing
to the installation location of the library. However, during
testing, the library won't be there yet. We much hence setup
a (DY)LD_LIBRARY_PATH that includes the dist/build dir.
Merge branch 'use-cabal-inside-cabal-exec' of https://github.com/benarmston/cabal
-Wall police
generate CURRENT_PACKAGE_KEY macro in `cabal_macros.h`
Merge pull request #2294 from luite/packagekey-macro

generate CURRENT_PACKAGE_KEY macro in `cabal_macros.h`
Do not fail when the setup executable does not exist when checking
for the windows clean hack.

This would cause exceptions when using a cached setup executable,
making parallel builds on Windows completely unusable.
bootstrap.sh: adapt to Cabal 1.22 version bump