GPURuntime compilation can "embedd" julia runtime values

[vchuravy]

@pxl-th reported on slack the following odd behavior.

During first execution exception reporting on AMDGPU (HIP rewrite) works fine, on the second one it
doesn't and the host code that tries to read the exception from the buffer sees a pointer to a type from the previous Julia session.

This could happen with Types/Symbols/... the works.

This is due to the fact that the runtime saves it bitcode to disk and re-uses it between sessions, so our usual assumptions of embedding
host pointers is fine, is no longer okay. This becomes even more relevant under generalized caching. (x-ref: #351 )

I see two paths forward:

1. We fix imaging mode and use it for code that will be cached. The current problem with imaging mode is that we are missing a mapping from GV to JL value. (This is an issue for StaticCompiler as well currently)
2. We do the Enzyme / StaticCompiler hack for the runtime. Find pointer values, rewrite them to GVs... carry on.

The former will likely need changes to Julia base, and the latter is "proven" but stupid.

[vchuravy]

@MasonProtter has probably the cleaner implementation https://github.com/tshort/StaticCompiler.jl/blob/master/src/pointer_patching.jl; Enzyme does it for a very different purpose.

We would need to save the runtime, along-side the relocation table and then when we load the runtime we perform relocation.

[maleadt]

Why not make it so that the runtime code doesn't contain exceptions? It was never meant to contain complicated IR, but more as a convenience to not have to write overly complicated LLVM.jl IR builders.