-dynload is a misfeature

GHC has a `-dynload` flag, which has two options: `deploy` and `sysdep`. This allows controlling ghc to either inject `rpaths` based on the packages it's trying to link an executable against, or (in the case of `deploy`, not set them).

The use of `-dynload deploy` was initially implemented in #2255 (commits: 06a713e1cf96482e325df09dd28770687f151dc9, 6c9dce4c0686061cfb8e2575dbe459c50701646d) a decade ago by @christiaanb for `cabal deploy` (which I don't think ever materialized).

`cabal-install` uses this feature to prevent ghc from passing `rpath` arguments to the linker. And then passes `-optl-Wl,-rpath,...` to ghc for all package libraries, _and_ thanks to @alt-romes fix in addbcbfbb7719eca3ab60f648a7ad37962f37afd also for `--extra-library-paths`.

This whole concept muddles a clean separation between ghc, and cabal, by cabal taking responsibility for something ghc should take care of.

1. Should cabal pass the `-rpath` for `--extra-library-paths`?

I do think yes, it should.

2. Should cabal pass -dynload deploy?

I do not think so. I think cabal should let ghc handle this, and defer this to GHC. It should be none of cabals business, the relevant metadata is encoded in the package database, and ghc should use that declaratively, instead of being told to _not_ use it, and then have cabal pass some extra linker flags outside of ghc. This just gives ghc much less control over the linking process, and means ghc and cabal can end up disagreeing on this.

3. What about that hypothetical cabal deploy command?

If cabal is to be used to move/package/bundle/deploy a dynamically linked program. First of all, I'd like to ask if this is really something _cabal-install_ should assume, or if this isn't better left to third party applications to do?

Should cabal end up wanting to assume this functionality, my preferred approach would be that cabal instead _rewrites_ the RPATHs in the executable _after_ ghc has built them, as a separate step, not by trying to interfere with ghc. This tight coupling of ghc and cabal just leads to interlocking and brittleness, in which both projects need to be very careful about the other.