Switch back to LLVM's IR linker

[pchintalapudi]

#44440 used jl_merge_module to merge ThreadSafeModules, but that function does not account for linkage type when merging and will not rename globals. Thus, we switch back to llvm::Linker which will take that into account. We may want to consider moving all of our uses of jl_merge_module to llvm::Linker.

Fixes #48093 with a new test.

[maleadt]

Thanks for looking into this!

#44440 used jl_merge_module to merge ThreadSafeModules, but that function does not account for linkage type when merging and will not rename globals. Thus, we switch back to llvm::Linker which will take that into account.

Ah yes, I actually switched that over to the LLVM linker in #36576, but didn't realize #44440 switched it back.

[maleadt]

Fixes the CUDA.jl issue, thanks!

[maleadt]

Windows CI is broken everywhere, so unrelated to this PR.

[maleadt]

Rebased and updated the test.

@vtjnash Given the restrictions with llvmcall, can you give your thoughts on how best to implement thread-local arrays for our GPU back-ends? Basically, we want to be able to:

function kernel(input::AbstractArray{T})
  buf1 = SharedArray{T}(undef, 1)
  buf2 = SharedArray{T}(undef, 1)
  ...
  return
end

i.e., we'd prefer to use functions not macros, but also the llvmcall needs to be produced by a generated function where we know about types and sizes (currently we forward the dims argument using Val to the generator function).

[maleadt]

CI failures are unrelated.