Original branch had freezes undone by
154a866 (hereafter: fix-hashable-mess),
erred on the side of going with its newer situation.
Doubts regarding my choices:
- The `hspec` major versions have increased since to 2.11.* (over 2.10.*
  referred to there)
  See below where I kept the old version
- `os-string` had a "bad" version 2.0.2.1 that was bumped everywhere,
  except in ghc{928,948}.Win32 where it had been at 2.0.2 -- it is
  unclear if that should've been bumped as well.
  Erred on the side of keeping those cases where the original branch had
  added `os-string ==2.0.3` given that that is the "good" version
- Some dependencies were only touched in some freezefiles by
  fix-hashable-mess, so I kept the cases where they weren't touched
  around:
  - `hspec`: ghc*.Win32, excluding ghc965.Win32
  - `tasty` and friends: ghc*.Win32, excluding ghc965.Win32
  - `setenv`: ghc*.Win32, excluding ghc965.Win32
  (I didn't know what the correct versions to use for ghc965.Win32 were,
  so I didn't try guessing)

Given the presence of cabal.ghc965.*, I assume that's the correct
version to target

Cf fix-hashable-mess, presumably this should be added here as well

This aids in diffing the two

Based on the behaviour of the other cabal.*.project files, introduced in
411ac8d. I'm presuming it was forgotten

As explained by @hasufell
> This is not correct. The release project file always wants to build
> with -tar. The tar flag is only there to circumvent complicated errors
> during development, which sometimes happens due to libarchive.

Add a note citing the above to the file to prevent future mixups

Given that we import most of the configuration from cabal.project,
there's no reason to duplicate it in cabal.project.release