ziglang
Support running LLVM backend in a separate thread
Closes #20635
@jacobly0
Most changes are quite straightforward, I did however have to move some Compilation mutex locking from Compilation.zig into PerThread.zig in order to fix a race condition on Zcu.import_tables. This seemed like the most reasonable solution as it's accessed all over the place in Sema.zig, but maybe it goes against some overarching locking strategy?
Backends should never be calling importPkg, another solution to this will need to be found before enabling llvm backend threading.
The only caller of importPkg seems to be getStackTraceType which is used when lowering function types. I threw together a bit of a hacky fix which stores the stack trace type inside the Zcu to test it if works.
What makes it "hacky" and what would a non "hacky" fix do differently?
Checking the value every time at the end of finishFunc feels a bit unnecessary, but maybe this it's a reasonable solution. I just wanted to point it out in case someone reviewing with more experience of the codebase had encountered something similar and had a better solution to initializing Zcu state.