Improve online docs for `includes:` field

Bases:
* https://downloads.haskell.org/~ghc/6.10.1/docs/html/users_guide/release-6-10-1.html
* https://hackage.haskell.org/package/Cabal-2.0.0.2/changelog
* https://github.com/haskell/cabal/commit/e1c39fc9ff4bf4eb8e956e2ee77da95d6cc73bbe

haddock-project support public sublibraries

Link test suites & benchmarks from the index.html; Provide the right
`--base-url` flag for them.

`--use-unicode` is added to `cabal haddock` and `cabal haddock-project`.
One cannot simply use `--haddock-option="--use-unicode"` because it
makes haddock to fail when building indexes.

Haddock should know the sublibrary name rather than just the package.
For sublibraries `package_name:sublib_name` is used. The name is
recorded in the `.haddock` file and used when haddock creates the
`index.html` file, e.g. when called by `haddock-project` command.

When running haddock-project `extra-doc-files` should be copied to
a subdirectories of the `argOutputDir` corresponding to the component.
This doesn't affect `haddock` command.

This commit makes haddock-project handle sublibraries.

The commit changes how `cabal haddock` works, changing the layout
in the `dist-newstyle` folder.  With this change `haddock` subcommand
will install `package:sublib` component in a directory `package-sublib`
under `l/sublib/doc/html/`.

The main library must use the package name rather than `UnitId`,
otherwise the links from other sublibraries will not work.

Cabal: Add flag to ignore build tool dependencies

Add a flag to disable the hard requirement on the
build-tools-(depends) declared on the Cabal package.

When this flag is enabled (--ignore-build-tools), a build-tool which
can't be found does not block compilation.

Fixes #10061

Make clear when pkg-config is not present

When no pkg-config program was found, cabal would
claim that the package is not in the db, instead
of telling clearly that no pkg-config was found at
all.

Remove a stray line from cabal-install changelog

See https://github.com/haskell/cabal/pull/9696#discussion_r1651689945
ff.

Use `--io-manager=native` in `lib-suite` on Windows

* Changelogs for 3.12.1.0 (#10124)

* changelog for 3.12.1.0

* fixup! changelog for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

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

* fixup! changelog for 3.12.1.0

* fixup! changelog for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

Co-authored-by: ffaf1 <fa-ml@ariis.it>

* fixup! Changelogs for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

---------

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>
Co-authored-by: ffaf1 <fa-ml@ariis.it>
(cherry picked from commit 2067ed19)

# Conflicts:
#	release-notes/Cabal-3.12.0.0.md

* fixup! Changelogs for 3.12.1.0 (backport #10124)

---------

Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

Add support for building profiled dynamic way

New options for cabal.project and ./Setup interface:

* `profiling-shared`: Enable building profiling dynamic way
* Passing `--enable-profiling` and `--enable-executable-dynamic` builds
  profiled dynamic executables.

Support for using `profiling-shared` is guarded behind a constraint
which ensures you are using `Cabal >= 3.13`.

In the cabal file:

* `ghc-prof-shared-options`, for passing options when building in
  profiling dynamic way

Other miscellenious fixes and improvements

* Some refactoring around ways so that which
  ways we should build for a library, foreign library and executable is
  computed by the `buildWays` function (rather than ad-hoc in three
  different places).

* Improved logic for detecting whether a compiler supports compiling
  a specific way. See functions `profilingVanillaSupported`,
  `dynamicSupported`, `profilingDynamicSupported` etc
  These functions report accurate infomation after ghc-9.10.1.

* Fixed logic for determining whether to build shared libraries. (see
  #10050)
  Now, if you explicitly enable `--*-shared`, then that will always take
  effect. If it's not specified then `--enable-executable-dynamic` will
  turn on shared libraries IF `--enable-profiling` is not enabled.

* Remove assumption that dynamically linked compilers can build dynamic
  libraries (they might be cross compilers.

* Query the build compiler to determine which library way is necessary
  to be built for TH support to work.
  (rather than assume all compilers are dynamically linked)

* An extensive test which checks how options for `./Setup` and
  `cabal-install` are translated into build ways.

Fixes #4816, #10049, #10050

* Disable arch-native flag when building releases that we distribute

* Use the constraints stanza

* Also disable the flag in cabal.validate.project

Skip tasty-quickcheck 0.11

API incompatible with our test suites

Depend on tar-0.6.3.0

Using the updated version of this library improves performance of
cabal-install so it's worthwhile to make sure the bootstrap plans use
this version.

tar-0.6.3.0 has much improved performance of deserialising .tar index
which has significant ramifications for the start-up time of
cabal-install.

See #10110

perf: Group together packages by repo when verifying tarballs

verifyFetchedTarball has the effect of deserialising the index tarball
(see call to Sec.withIndex).

verifyFetchedTarball is called individually for each package in the
build plan (see ProjectPlanning.hs). Not once per repo.

The hackage tarball is now 880mb so it takes a non significant amount of
time to deserialise this (much better after haskell/tar#95).

This code path is important as it can add 1s with these 38 calls on to
the initial load of a project and scales linearly with the size of your
build tree.

Reproducer: Simple project with "lens" dependency deserialises the index tarball 38 times.

Solution: Refactor verifyFetchedTarball to run once per repo rather than once per package.

In future it would be much better to refactor this function so that the
items are not immediately grouped and ungrouped but I didn't want to
take that on immediately.

Fixes #10110

* Add MHS as a recognized compiler.

* Add Changelog entry

* Add comment.

* Update checksums.

* Update more checksums.

---------

Co-authored-by: Lennart Augustsson <lennart.augustsson@epicgames.com>

Be more careful in handling unconfigured programs in the program database

There was some hacky logic in place to give a "haskell-suite" compiler
a dummy location so that we would attempt to configure it.

This logic is no longer necessary since 'configureRequiredProgram' was
changed to accomodate the situation in which 'lookupKnownProgram' fails.
In fact, it is downright harmful, as this dummy location will trigger
errors when we attempt to configure all known programs, which is
a necessary step before attempting to serialise a program database.

This commit configures the unconfigured programs in the program database
when we are building a custom Setup script. This ensures that we can
find the "strip" program which might otherwise still be unconfigured.

In configureRequiredProgram, we would unconditionally configure the
program, even if it was configured already. To explain why this is
problematic:

  - The programs we try to configure in this function are those that
    arise from a "build-tool-depends" field of a package.
  - If the program is not in the "unconfigured" state, we would
    unconditionally treat it as a simpleProgram.
    This means that if such a program is builtin but is not a
    simpleProgram, we might fail to configure it properly.

This problem arises when we configure programs more eagerly: when, in
the past, we might have gone looking up an unconfigured program and
successfully configured it, now we might find the program is already
configured.

One example in which this would cause an issue is when we have

   build-tool-depends: hsc2hs

If we end up re-configuring hsc2hs in configureRequiredProgram, we would
treat it as a simple program, which would cause us to be unable to
determine its version.

We should configure unconfigured programs before serialising them
(using the Binary ProgramDb instance) in
Distribution.Client.ProjectPlanning.configureCompiler, as otherwise
we can accidentally discard information.

This isn't currently a live bug, because in practice we end up
re-running configuration steps when interfacing with the Cabal library.
However, in the bright future in which we avoid re-configuring things
when building a Cabal package that we already determined when invoking
cabal-install, this starts causing problems.