Segfault in HLS testsuite with ghc 9.10.3 due to (b9f49013061efcb2ae1d0986fdad3baf39994067)
## Summary
@wz1000 and me traced back a segfault in HLS starting with 9.10.3 to commit b9f49013061efcb2ae1d0986fdad3baf39994067.
We should revert/Fix "rts/linker/PEi386: Don't repeatedly load DLLs" (b9f49013061efcb2ae1d0986fdad3baf39994067)
It's unclear the exact reason why it happens at this point but it seems the strings that should refer to dlls get corrupted and end up pointing to garbage instead.
This is dependent on GC timings. Running the tests with a sufficiently large nursers avoids the crashes. My theory at this point is that we store the address and some kind of `ByteArray` and only pass the pointer to the RTS. With things going havoc down the line when the haskell array get's gced. But we are still actively investigating this.
The issue seems to be that the HLS testsuite driver loads multiple files involving TH. To do so it loads various libraries. Eventually it segfaults during loading one of those libraries with a backtrace like:
```
#0 0x00007ffee0f25896 in wcscmp () from C:\WINDOWS\System32\ucrtbase.dll
#1 0x00007ff6e5eadbaf in compare_path (key1=140690156649928, key2=140690141339840) at rts\linker/PEi386.c:556
#2 0x00007ff6e5e997d8 in lookupHashTable_inlined (table=<optimized out>, key=140690141339840, f=<optimized out>, cmp=0x7ff6e5eadb90 <compare_path>) at rts/Hash.c:226
#3 lookupHashTable_ (table=<optimized out>, key=140690141339840, f=<optimized out>, cmp=0x7ff6e5eadb90 <compare_path>) at rts/Hash.c:238
#4 0x00007ff6e5ea7510 in isDllLoaded (cache=0x7ff6ecb365a0, dll_name=0x7ff4f9e5e0c0 L"C:\\WINDOWS\\system32\\wsock32") at rts\linker/PEi386.c:566
#5 0x00007ff6e5ea72d6 in addDLL_PEi386 (dll_name=0x7ff4f9e5e0c0 L"C:\\WINDOWS\\system32\\wsock32", loaded=0x368dc38) at rts\linker/PEi386.c:945
#6 0x00007ff6e5865dd1 in loadNativeObj (path=0x7ff4f9e5e0c0 L"C:\\WINDOWS\\system32\\wsock32", errmsg=0x7ff4f9e5e108) at rts/Linker.c:1841
#7 0x00007ff6e7e0a1b0 in hs_atomicwrite64 ()
#8 0x0000000000000000 in ?? ()
```
The hs_atomic in the backtrace is confusing, but I'm not sure it's relevant.
## Steps to reproduce
TODO
## Expected behavior
No segfaults.
## Environment
* GHC version used:
Optional:
* Operating System:
* System Architecture:
issue