ldProgram is misleading

Cabal has long had `ldProgram :: Program`, which gets resolved to the `ld` executable. One would be forgiven for thinking that Cabal would use this program for linking in some cases. Furthermore, `LocalBuildInfo` has an `ldOptions` field which one might think should get passed to `ldProgram`. Both of these beliefs are mistaken. The reality is much more complicated:

* typically (read: almost always) the Haskell compiler is responsible for linking
* Cabal passes the options of `programOverrideArgs ldProgram` to the Haskell compiler during when linking
* in the case of GHC (and, I would guess, most implementations) the Haskell compiler uses the C compiler to link, not `ld`
* When probing foreign dependencies, `Cabal` *does* do some linking on its own. However, it, like GHC, uses the C compiler to link (and passes `LBI.ldOptions`, but not `programOverrideArgs ldProgram`, when doing so.

All of this is understandable; GHC was also quite confused about linking for quite a long time. However, the status quo is becoming increasingly problematic as cross-compilation becomes more common. In particular, recently GHC found that Emscripten's toolchain happily accepts the `--target` flag when invoked as a linker yet not during compilation (see [ghc#23744](https://gitlab.haskell.org/ghc/ghc/-/issues/23744)). To manage this, GHC had to begin making a distinction between `cc` and `cc-ld` tools (that is, the C compiler used for compilation and the C compiler as used for linking).

Ultimately I'm not familiar enough with Cabal's design vision to know what a better design might look like but I think it's something that we may want to consider.

Begin by tracing the existing ldProgram, ldOptions, and programOverrideArgs paths described in the issue, including compiler linking and foreign-dependency probing. The intended distinction between compilation and linking tools must be established before implementation; the issue names no files or tests and does not define a finished design.

Written by the indexing model from the issue text.