Covers 3 of the 4 possible cases:
1. explicit custom setup deps
2. custom setup with implicit/default deps
4. non-custom setup using the internal cabal lib version

case 3 is a non-custom setup but where we're forced to use an external
cabal lib version. This case is hard to test since it only happens when
it's a newer (not older) Cabal lib version that the package requires,
e.g. a .cabal file that specifies cabal-version: >= 2.0.

Also, add a --with-ghc option to the integration test suite, which lets us
more easily test with different ghc versions.

Also, don't use parallel builds in any of the integration tests, as the
self-exec method will not work, and some tests need to install deps for
some ghc versions.

Commit 2f976576 added default setup dep
handling to the existing install command code paths, but unfortunately
broke the handling for the new-build code path. It added a call to
addDefaultSetupDependencies into the standardInstallPolicy. That
interfered with the addDefaultSetupDependencies that ProjectPlanning was
already using.

So this patch splits a basicInstallPolicy out of standardInstallPolicy,
where the basicInstallPolicy is all the old stuff, and the
standardInstallPolicy just adds the addDefaultSetupDependencies that the
install/fetch/freeze commands need. So then ProjectPlanning uses just
the basicInstallPolicy.

The 2f976576 commit also added a new and simpler method to determine if a
package has had default setup deps added. Previously ProjectPlanning had
to use a rather complex method to remember this information. So this
patch removes all that and makes use of the new method.

To stop this breaking in future the next patch adds integration tests to
cover custom setup script handling.

This fixed issue #3394.

Add a regression test for issue #3324

Use base not haskell2010 package.

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.