ghc-shim: add unlit / ghc-iserv-{,dyn,prof} aliases for native-musl ≥ 9.10
Mirror v1's `ghc-for-component-wrapper.nix:136-139` workaround in v2's slice builder, and add `ghc-iserv-dyn` to v1.
Native-musl cross-ghc ≥ 9.10 ships only `<prefix>unlit` / `<prefix>ghc-iserv[-dyn|-prof]` in its `bin/` (no unprefixed alias). GHC's literate / iserv lookup is relative to its own binary path (`<topdir>/bin/unlit`), so without an unprefixed alias under `<topdir>/bin/` it fails with `Literate pre-processor: could not execute …/bin/unlit`.
Fix in `build-cabal-slice.nix`: on native-musl ≥ 9.10, lndir real ghc's libdir into the shim, wrap the ghc binaries with `-B$out/<libRel>` (computed from `--print-libdir`), and add unprefixed aliases for `unlit` + `ghc-iserv*`. The aliases are guarded on existence so a ghc lacking `ghc-iserv-dyn` (ghc967, ghc984) skips that one alias rather than dangling.
Fix in `ghc-for-component-wrapper.nix`: add `ghc-iserv-dyn` to the existing alias block.
Surveyed real ghc bin/ across ghc967, ghc984, ghc9103, ghc9124, ghc9141 musl64: 9.10+ have all four binaries; 9.6 / 9.8 have none (and their `>9.9` / `>=9.10` gate doesn't fire, so they don't try).
Verified passing on x86_64-linux.unstable.ghc9103.musl64.tests.literate-haskell.build.
![sg-doc-holiday[bot]](https://avatars.githubusercontent.com/in/1508860?v=4&s=80)
![hercules-ci[bot]](https://avatars.githubusercontent.com/in/24794?v=4&s=80)