Work around dlopen not working properly under sanitizer instrumentation

[Keno]

dlopen has a mis-feature where it looks at the return address to determine the calling object to look at it's RUNPATH. Because asan intercepts dlopen, the calling object check finds asan rather than julia, causing an incorrect RUNPATH (and other flags to be used). Arguably, this is mostly a libc problem, because there isn't really a way to directly specify the resolution scope. I have sent a proposal to libc-coord [1] to fix this, but of course, we can't wait for that to percolate down to us. Instead, this takes advantage of the fact that almost all of our dlopen calls go through a single entrypoint in jl_dlopen, so we can insert additional logic here to make this work. This doesn't catch uses of dlopen in jlls (which is a problem for things like plugin loading in various jlls), but it at least makes base julia work. We can punt the jll question to another day - either with a patched libc in PkgEval or by patching the jll source with an analogous patch.

Regardless, with this, Julia bootstraps properly under asan, without any special LD_LIBRARY_PATH hacks.

[1] https://www.openwall.com/lists/libc-coord/2022/08/04/1

[vtjnash]

Apple has an API for exactly this purpose, but it is private: https://github.com/apple-oss-distributions/dyld/blob/5c9192436bb195e7a8fe61f22a229ee3d30d8222/include/dlfcn_private.h#L53-L58