Add miscellaneous changelog fixes

* Bumpo “Redefine `build-type: Configure`” importance

* Move “`pkg-config` error message” entry

to “Other changes”

* Fix typo

* cabal file → `.cabal` file

* Remove #9702 from `cabal-install` changelog

It is invisible to `cabal-install` user

* Changelog: add OrPatterns extension

* Changelog: add SPDX note

* Make release notes for cabal-install 3.14

We are after all releasing cabal-install 3.14

* Fix SPDX entry

We are not doing the sensible thing anymore.

Bump actions/cache from 3 to 4 (backport #9646)

Bumps [actions/cache](https://github.com/actions/cache) from 3 to 4.
- [Release notes](https://github.com/actions/cache/releases)
- [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md)
- [Commits](https://github.com/actions/cache/compare/v3...v4

)

---
updated-dependencies:
- dependency-name: actions/cache
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
(cherry picked from commit 3a6f73ed)

[3.14] Bump version numbers to 3.14

It includes a compatible hackage-security

* changelogs for Cabal-3.14 and (incomplete) cabal-install-3.16

* cleanup changelog-d files afer creating the 3.14 changelog

* Apply suggestions from geekosaur

Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>

* Apply more suggestions from geekosaur

* Apply suggestions from geekosaur (contd.)

Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>

---------

Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>

* Improve bat scripts for CCompilerOverride

* Ensure Windows tests can cleanup the temp directory

* Implement `flaky` combinator

* Remove outdated tests

* Remove broken tests

These tests were testing for messages that were removed with the `cabal check` rework.

* Make `skip` and `broken` messages uniform

* Mark flaky tests

* Re-enable DeterministicTrivial

* Fix MacOS canonical paths

* Extend cabal-testsuite readme with `flaky`

* Skip non-terminating tests in Windows CI

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

Re-enable Windows CI

CI: validate: don't fail-fast

Which means that if a Windows job fails, all other jobs in the matrix
will be allowed to finish (other platforms, as well as other compilers on Windows, etc.)

Inspired by the discussion at https://github.com/haskell/cabal/issues/10263

make sure cabal-install is compatible with Cabal

See https://github.com/haskell/cabal/issues/9833

If a ghc ships with a compatible Cabal, it will be preferred by
the solver on `cabal install cabal-install`; the new `cabal-install`
should in fact be compatible. So we test this on release branches
that have had at least one release on Hackage. (Ideally we'd check
ghc instead, but we can't do that from GHA. Even checking Hackage
is pretty painful.)

Collection of patches to do with --working-dir 

Before the previous patches this test failed because an incorrect path
was passed to hsc2hs (a preprocessor), it now succeeds :)

When testing `./Setup` only, when `withDirectory` is used, instead of
changing into that directory when invoking processes, we now use the
`--working-dir` flag and keep a fixed CWD.

This will therefore passively test that `--working-dir` is working

In addition, it makes it possible to test things easily such as
`--working-dir` with a relative path as an argument. `cabal-install`
will only invoke `--working-dir` with an absolute path and hence is
isolated from any double interpretation issues.

Testing against these double interpretation issues is very important as
it also prevents over-interpretation of relative paths into absolute
paths. Passing absolute paths to tools such as hsc2hs can lead to the
build directory leaking into an interface file which leads to
non-reproducible results.

runDbProgram doesn't take into account the working directory (so will
normally produce incorrect results when used in `Cabal`). This replaces
the last uses which weren't found by testing, they were found by
grepping.

There are a few places where paths are known to be absolute. This
enforces that in the type system by introducing a simple wrapper to
`Distribution.Utils.Path`.

```
newtype AbsolutePath (to :: FileOrDir) = AbsolutePath (forall from . SymbolicPath from to)
```

The nice thing about this abstraction is when when a path is unwrapped,
due to the universally quantified `from` type, the resulting
`SymbolicPath` can be used with any API which expects a path to point
`from` a specific directory.

This refactoring enforces a simple property

* We use symbolic paths in Cabal in order to represent that paths to
  package databases. These paths is relative to the package root.
* We use normal filepaths in cabal-install to represent the path to a
  package database. These are relative to the current working directory.

Paths are explicitly converted from one type to the other at the
interface of `cabal-install` and `Cabal`, see `setupHsConfigureArgs` for
where this happens.

In order to achieve this `PackageDB` is abstracted over what the type of
filepaths a specific package db points to.

```
type PackageDBX fp = ... | SpecificPackageDB fp | ...
```

If you are using the Cabal library then you probably want to migrate to
use `PackageDBCWD` and `PackageDBStackCWD`.

```
type PackageDBCWD = PackageDBX FilePath
type PackageDBStackCWD = [PackageDBCWD]
```

Then at the point where you call commands in the `Cabal` library convert
these paths into paths relative to the root of the relevant package.
The easiest way to do this is convert any paths into an absolute path.

This patch fixes a double interpretation issue when the `--working-dir`
option was used and package db paths were offset incorrectly.

This fixes the --gen-pkg-config to use the symbolic path abstraction, in
turn this ensures that we interpret the path appropiately when
`--working-dir` is also set.

This fixes a simple oversight where the flags were passed without
updating the `--working-dir` argument appropiately.

It is only on Cabal 3.13 that the symbolic path abstraction was
introduced.

On CI we only test with Cabal master so the incorrect bound wasn't
picked up.

Include package version in --promised-dependency flag

In the original implementation of promised dependencies I accidentally
left over the hard coded `currentCabalId` in the `configureDependencies`
function.

This led to several errors happening later when the package name and
version would be incorrect if you looked at this field (package
arguments are not computed using it), it is used when generating cabal
macros and something in the haddock options.

The solution is to pass the package version in the
`--promised-depenency` flag so the format is now

```
NAME-VER[:COMPONENT_NAME]=CID`
```

rather than

```
NAME[:COMPONENT_NAME]=CID
```

Fixes #10166

add "ready and waiting" Mergify label

The bot can use this to announce PRs that are entering the 2-day
waiting period.

update the pinned index-state to get the new `rere`

Without this, #10202 breaks `cabal.project.release` on ghc 9.10.1.

ci: Fix --index-state for hackage roundtrip tests

As a principle, tests which are required for CI to pass should be
reproducible and not depending on external resources changes or being
modified. The hackage tests currently violate this by depending on the
latest index state from hackage. This is problematic because until the
test is fixed all merges into master are blocked. Even though the
patches in question have nothing to do with the test.

It would be more suitable for a nightly job to run on the latest index
and for normal CI to run with a fixed index which is updated
periodically in a controlled manner.

Fixes #10284

We need to fix the index-state we test against so a new bad cabal file
doesn't take down the CI for everyone.

Towards #10284

* Add ProjectRootUsability datatype

* Make findProjectRoot aware of broken files

* Add changelog entry

* Fix typos

tests: Make structured hash tests invariant to GHC version

In 9.8 the Generic instance for tuples changed (see
ghc/ghc#24291) for more details.

Therefore we remove the dependency on the `Generic` instance and the
hashes will be invariant across GHC versions (for now).

Fixes #10269