Otherwise CI prints `validate.sh: 332: [[: not found` and the line
does nothing (but `validate.sh` continues to run), unless the
system shell is `ksh` / `bash` / `zsh`. This may explain
https://github.com/haskell/cabal/pull/10114#issuecomment-2178163927.

- Rename cabal.bootstrap.project
- Rename cabal.meta.project
- Rename cabal.validate-libonly.project
- Rename cabal.validate.project
- Rename cabal.release.project

This commit introduces a new build-type, Hooks. A package using this
build type should provide a SetupHooks.hs module which exports
a value `setupHooks :: SetupHooks`. This is intended to replace the
Custom setup type. This allows Cabal to have finer-grained information
about the build, instead of having an opaque Setup executable to invoke.

Tests include:

  - error when returning an invalid component diff in a
    per-component pre-configure hook
  - error when declaring pre-build rules whose dependency
    graph contains cycles
  - error when we cannot find a dependency of a pre-build rule
  - warning when there are pre-build rules that are declared but
    never demanded
  - correctness tests for SetupHooks, e.g. that
    pre-build rules are run in dependency order (see the
    `SetupHooksRuleOrdering` test)

The idea here is to pass a `--package-db` flag to `cabal-install` which
contains just `Cabal` and `Cabal-syntax` of the specific version. This
allows `cabal-install` tests to use the in-tree `Cabal` version,
something which you can easily run into and get very confused about when
writing tests.

There are a few options which can be passed to `cabal-tests` executable
to control which Cabal library you will test against.

1. --boot-cabal-lib specifies to use the Cabal library bundled with the
   test compiler, this is the default and existing behaviour of the
   testsuite.
2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax
   from a specific directory, and `--test-tmp` indicates where to put
   the package database they are built with.
3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal
   version from hackage (ie 3.10.2.0) and installs the package database
   into --test-tmp=<DIR>

The end result is that changes in the Cabal library can be tested with
cabal-install tests in the testsuite.

There have been a number of confusing issues with people writing tests
for changes in the Cabal library which never ran because of
cabal-install tests always used the boot Cabal library (see #9425
for one).

Fixes #9681

Remove v2-prefix from other documentation where appropriate

* Added a changelog file

* Merge branch 'master' of github.com:haskell/cabal into remove-v2-from-docs

* Implemented PR feedback

* Reverted changes to regression tests

* Update CONTRIBUTING.md

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>

* Update bootstrap/bootstrap.py

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>

* Apply suggestions from code review

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>

* Merge branch 'master' into remove-v2-from-docs

* Removed changelog entry

* Merge branch 'remove-v2-from-docs' of github.com:aspidites/cabal into remove-v2-from-docs

* Reverted bootstrap/README.md

* Merge branch 'master' into remove-v2-from-docs

Co-authored-by: ulysses4ever <6832600+ulysses4ever@users.noreply.github.com>

This reverts commit e159a12c.

Closes #8440

* Changes needed for GenValidate and release.py to
  accommmodate new solver dependency
* Bumps bootstrap plans to modern GHC versions
* Update `validate.sh` and `release.py` to accommodate new solver dep.
* Update `Makefile` targets

The are various motivation points:
- I'm not aware anyone third party running Cabal tests (maybe nixpkgs?)
- No need to do gen-extra-source-files, as Cabal-tests is not distributed
- No multiple rebuilds of Cabal-QuickCheck, Cabal-tree-diff
- Slightly smaller Cabal sdist (which is quite big still)

Previously this would work until CABAL_TESTSUITE_BDIR was needed, at
which point it would fail because it looked for things under
.../ghc-8.6/... while cabal v2-build actually put them in
.../ghc-8.6.5/...

Hard-coding "ghc" is unfortunate, but I didn't know if there was an easy
way to avoid it.  I also didn't want to over-complicate it, until it was
necessary.

validate.sh isn't tested in CI so...
[ci skip]

In recent versions of cabal-plan the --builddir= flag has become a
non-global flag; i.e. it needs to be placed after the sub-command rather
than before.

`validate.sh` isn't tested in CI so...
[ci skip]