This commit makes it so that cabal-install emits PackageDescription
parser warnings at normal verbosity or above. Previously, we used to
emit warnings at verbosity >= verbose, but now that we are going through
in-library methods this meant we could skip ever emitting some warnings,
which is not desirable.

This commit modifies the SetupWrapper mechanism, adding a new way of
building a package: directly calling Cabal library functions (e.g.
'build', 'configure' etc).

This currently requires a bit of GADT trickery to accomodate the fact
that configure returns a LocalBuildInfo which must then be passed to
subsequent phases, while with the old Setup interface everything returns
IO () and communication is done through the filesystem
(the local build info file).

To handle 'build-type: Hooks', this commit introduces the hooks-exe
package, which contains:

  - the hooks-exe library, used to compile a set of SetupHooks into an
    external executable,
  - the hooks-cli library, which is used by cabal-install to communicate
    with an external hooks executable.

This package depends on the new `CommunicationHandle` functionality from
haskell/process#308.

The `hooks-exe` package enables `SetupHooks` values to be converted into
a `Setup.hs` executable which can be executed independently of Cabal.
The `Setup.hs` executable wrapping `SetupHooks` is quite important to
preserve the interface used by other tools when packages migrate to
`Hooks` from `Custom`.

Even though `hooks-exe` is an internal dependency required by the `Setup.hs`
wrapper around `SetupHooks`, it is a dependency nonetheless.

Given the internal nature of `hooks-exe`, we don't want to impose on our
users the obligation to add a dependency on `hooks-exe` in their
setup-depends field. Instead, we want `hooks-exe` to be implicitly added
to the setup dependencies. This commit does that exactly.

This commit updates the bootstrap plans to account for the new
local hooks-exe package, which cabal-install depends on.

This commit contains testsuite changes to account for the change in
how cabal-install calls Cabal.

The most common change is that we emit warnings at a slightly different
point during compilation.

This SetupMethod is no longer used; it is replaced by the InLibrary
SetupMethod which directly calls Cabal library functions instead of
going through defaultMain.

This moves some functions to the top-level and threads through the
required arguments. This helps to separate concerns a bit more, as
opposed to having all functions defined in one big blob.

`reusingGHCCompilationArtifacts` assumed the existence of a build folder
where objects were written (even if empty), but with InLibrary calls
this is no longer necessarily true.

Previously, the build folder ended up always existing because the call
of `configure` through `Setup` created the folder.
However, now that we may call Cabal the library directly, the existence
of this directory is no longer guaranteed.

Easy fix: don't try to copy the build folder if it doesn't exist yet.