This means we only have to update the llvmPackages attribute in one
place now and should prevent situations like with 8.6.5 where different
versions would be used in the package set compared to the compiler
build.

Drop comments in the configuration-ghc-X.Y.x.nix files as well, since
LLVM version isn't tied to the compiler minor version at
all (e. g. 8.10.2 and 8.10.7 have different support ranges).

GHC 9.0.1 only supports LLVM 9 and spews a lot of warnings about LLVM 10
when using the LLVM backend atm.

See also: https://www.haskell.org/ghc/download_ghc_9_0_1.html

Source:

* (8.6.5: https://www.haskell.org/ghc/download_ghc_8_6_5.html)
* (8.8.4: https://www.haskell.org/ghc/download_ghc_8_8_4.html)
* (8.10.2: https://www.haskell.org/ghc/download_ghc_8_10_2.html)
* 8.10.7: https://www.haskell.org/ghc/download_ghc_8_10_7.html
* (9.0.1: https://www.haskell.org/ghc/download_ghc_9_0_1.html)
* 9.2.1: https://www.haskell.org/ghc/download_ghc_9_2_1.html
* HEAD: https://gitlab.haskell.org/ghc/ghc/-/blob/3ab3631f41efe9a1ae32a5b1f709152228edb09a/configure.ac#L674

GHC 8.6.5 will always segfault on aarch64-linux and at this point
it's not realistic we'll ever fix this.

haskell.compiler: refactor LLVM handling, upgrade to latest LLVM version for each GHC version

Copy the approach from the normal GHC derivations for adding an
`export PATH` into the scripts in `$out/bin` and use it to put the
specific LLVM version of the binary GHC into its PATH. This will
prevent the LLVM version of the GHC we are building later to take
precedence over the LLVM version this GHC needs.

This brings the binary GHCs on parity with the source built ones in
terms of the wrapper. The upshot of this is that compiling something
using the binary GHCs no longer depends on PATH being populated with
the tools included in stdenv at all. We can even test this by running
the installCheck with an empty environment (via `env -i`).

This will prevent freak accidents where the wrong tools are used because
they are in PATH by chance.

This has two main benefits:

* GHC will work reliably outside of stdenv, even when using -fllvm since
  everything it'll call at runtime will be provided in PATH via the
  wrapper scripts.

* LLVM will no longer leak into haskell packages' configure
  scripts. This was an issue with llvm-hs which fails to build if the
  LLVM version of the compiler since the propagatedBuildInputs of GHC
  take precedence over the nativeBuildInputs added in the derivation.

Since GHC now will have LLVM available when needed, we don't need to add
it in the wrapper anymore. It can still be added if NCG is available,
but -fllvm should be used (e. g. to work around an NCG bug).

aarch64-darwin NCG was added in 9.2.1 which makes it unnecessary to
include LLVM in the wrapper.

See the added comment in all-packages.nix for a more detailed
explanation. This makes the top-level GHC different from
haskellPackages.ghc (which is build->host and used for building the
package set), but more consistent with gcc, gnat etc.

Specifically, pkgsCross.${platform}.buildPackages.ghc will now be a
cross-compiler instead of a native build->build compiler.

Since this change has a slight chance of being disruptive, add a note to
the changelog.

GHC can actually accept absolute paths for its runtime tools (except for
touch) at configure time which are then saved in
`$out/lib/ghc-${version}/settings`. This allows us to drop the wrapper
entirely if we assume that a POSIX compliant touch is in PATH when we
run GHC later.

The touch problem can presumably be fixed by either patching the
configure file of GHC (although we need to take care not to change the
touch GHC uses during its compilation) or messing with the settings file
after installation.

The rationale for dropping the wrapper PATH entry completely is that
it's always possible to invoke GHC via its library which will bypass the
wrapper completely, leading to subtly different behavior.

Binary GHCs are not touched in this commit, but ideally they'll get a
similar treatment as well, so they are more robust, although we
generally don't need to use them as a library.

Note that GHC 8.8.4 doesn't care about install_name_tool or otool, so
the respective environment variables are not set.