Support running LLVM backend in a separate thread

[antlilja]

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?

[jacobly0]

Backends should never be calling importPkg, another solution to this will need to be found before enabling llvm backend threading.

[antlilja]

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.

[andrewrk]

What makes it "hacky" and what would a non "hacky" fix do differently?

[antlilja]

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.