ABI mismatches of GHC bindists

GHC 9.0.2 on linux and 9.2.2 on [windows](https://gitlab.haskell.org/ghc/ghc/-/issues/21190) had missing profiling libs so @mpickering was so kind to supply me with fixed bindists.

These were added to ghcup: https://github.com/haskell/ghcup-metadata/commit/88696a0cc5ebb8fe5b15662f6a840be7c1cdd699

Since profiling seems to affect the ABI, this caused a number of issues:

* https://gitlab.haskell.org/ghc/ghc/-/issues/21423
* https://gitlab.haskell.org/ghc/ghc/-/issues/21423#note_424246

The latter being that stack with GHC 9.0.2 doesn't work with HLS, because they still use the old bindist without profiling libs, causing ABI mismatch in our wrapper script: https://github.com/haskell/haskell-language-server/blob/6742c205c8386a2898d3a8baa830ecc75713845d/bindist/wrapper.in#L77

This begs the question on how to deal with such diverging ABI. I see a couple of potential solutions:

1. coordinate bindist updates with stack team
2. have hls-wrapper binary pick the correct ABI (in addition to correct GHC version) and ship multiple hls binaries, such as `haskell-language-server--`
3. somehow integrate better with stack and require users to use ghcup for GHC installation (see https://github.com/commercialhaskell/stack/pull/5585)
4. make compiling from source more robust, so that e.g. the VSCode extension could compile HLS from source on ABI mismatch instead of giving up

Also note that there may be other cases where ghcup and stack bindists diverge, e.g. because they have different platform detection logic.