Add function to emit multiple CodeInstances to the JIT atomically (remove jl_typeinf_lock) (#61255)

`jl_typeinf_lock` was introduced because it was easy to observe
performance regressions when running code that triggered type inference
on multiple threads. These changes prevent the unexpected invoke
trampolines and remove the type inference lock.

The typical situation is this: let f() and g() be functions, where f()
calls g(). Thread 1 triggers inference for f(), which also infers g().
Then, in `add_codeinst_to_jit!`, thread 1 adds the code for f(), which
becomes visible to other threads because the `invoke` field of the
CodeInstance is set to `jl_fptr_wait_for_compiled` [1]. Before thread 1
adds g() to the JIT, thread 2 comes along, sees the invoke field on f()
and attempts to invoke it. The JIT must then compile a tojlinvoke
trampoline to g(), because it does not yet have IR for it.

This PR renames `jl_add_codeinst_to_jit` to `jl_add_codeinsts_to_jit`
and makes it take a vector of CodeInstances and a vector of CodeInfos.
We then emit all of the CodeInstances to a single `jl_codegen_output_t`
and add it to the JIT with `JuliaOJIT::addOutput`. The JIT, while
holding `JuliaOJIT::LinkerMutex`, sets the `invoke` pointer for every
defined CodeInstance to `jl_fptr_wait_for_compiled`. If another thread
has compiled that CodeInstance in the meantime, we skip it. If another
thread observes the invoke pointer we have just set, it's okay because
it will block waiting to acquire `LinkerMutex` if it attempts to invoke
it.

This pull request also changes the condition in
`JuliaOJIT::linkCallTarget` to match `add_codeinst_to_jit!` to avoid a
few other unnecessary trampolines: namely, we know an equivalent
CodeInstance will have been emitted to the JIT only if the target
CodeInstance is not in the global cache (since that's what inference
checks).

[1] In practice you need another function, because of the order
`add_codeinst_to_jit!` collects invokes in, but it would complicate the
presentation.