New build exception handling

These integration tests, unlike the existing ones, don't call cabal as
an external processes. Instead they use the cabal code directly. This
makes it possible to conveniently test catching exceptions.

Add a couple tests for exceptions in finding projects. There should be a
lot more for the various phases of planning.

Also add a couple tests for exceptions in the configure and build
phases. These test the previous patch that improves the exception
handling so that failures are added into the residual plan rather than
just propagating immediately.

Include cabal.project files too.

[ci skip]

Fixes #3414.

Fix various behavior differences between the transports

Previously, the wget transport would never return the text of the response
that we receive from the server. For example, when uploading a package candidate,
the server normally responds with a list of warnings that affect the package. But
if you used the wget transport, it only returned a response like "OK". This commit
uses the wget option `--output-document` to capture the server response and return
a correct response.

Again, all the other transports already set an Accept header, so
the wget transport should also set it.

All the other transports already do follow redirects, so we
should do the same for the curl transport for consistency.

Fixes #3426

[ci skip]

upload: don't allow 'publish' in cabal.config

This hides the "publish" flag, so it is not possible to set publish from
cabal.config. Previously, cabal would successfully accept a line "publish: publish"
in cabal.config, but it wouldn't change anything. Now, setting this
field is no longer allowed.

We could have instead allowed setting a default behaviour for publishing packages
in the config file, but it would make the user interface more difficult, since
cabal upload would then have to support three options for setting IsCandidate:
use from config (default), publish (override config), candidate (override config).

Remove 'upload --check'.

[ci skip]

Fixes #1823.

cabal upload: support package candidates

The message now includes a link to the package page and says
whether the package was uploaded as a candidate or not.

When uploading package candidates, the hackage server will return 204 responses in some cases.
The upload was still successfull in that case though.

We now also display warnings that the hackage server gives when a package is uploaded.

This adds support for uploading package candidates by introducing a new flag to `cabal upload`,
--candidate. With this flag, `cabal upload` will upload all supplied tarballs as package candidates.
If combined with `--documentation`, the flag can also be used to upload documentation for a package
candidate to hackage.

Fixes #3418

Add (optional) tracetree support into the cabal executable

Add an AUTHORS file and simplify copyright notices.

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]