* use queues
* rebase+merge strategy
* merge+squash strategy

Signed-off-by: Francesco Gazzetta <fgaz@fgaz.me>

- regenerate bootstrap plans
- update CI and docker images for 8.8.4 and 8.10.4

* 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

I want to use stack diffs (https://github.com/ezyang/ghstack/

) to
submit PRs to Cabal.  Stack diffs, simply by virtue of what they
are, are PRs that are targeted to branches that are not master (they
target an appropriate base that lets GitHub render only the change
in question, even if there are other changes below it.)  However,
I don't get CI jobs on those stack diffs because the current
pull_request branch selector is too restrictive.  This PR makes
it less restrictive.

This PR is submitted using ghstack to validate that this indeed
works.

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

ghstack-source-id: b135ea67848f873fc6b50b950405859587ae8d89
Pull Request resolved: https://github.com/haskell/cabal/pull/7308

8.6 was no longer included in the image

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)

A script essentially runs `v2-install cabal-install:exe:cabal`,
but does some simple setup, so the result is less luckily
to be influences by environment.

Also improve bootstrap to do out-of-tree builds.
- Use http, https tricky in some environments

https://github.com/actions/virtual-environments/blob/releases/ubuntu18/20200604/images/linux/Ubuntu1804-README.md

- msys2 should be installed
- there is cabal and GHC, but we want to be sure about
  versions, so we reinstall.
- Reinstalling GHC doesnt' "just work", so we uninstall it first.
  This takes time, but makes CI work.

- [ci docs] doesn't work.
  We require CI to pass for non-admins to merge, so `[ci docs]` is
  more harmful. Also GitHub actions are reasonably fast,
  so overall it's ok to let it make builds

- Mention `changelog.d` directory

Also add validate-8.10.1 make rule