Investigate difficulties with using libjimage

[RyanGlScott]

This was originally spun out of GaloisInc/saw-script#861, where we discussed the most efficient way to read classes from JIMAGE files, which modern versions of Java use. One possibility raised in GaloisInc/saw-script#861 was using libjimage, a standalone C++ library bundled with JDK installations, to parse JIMAGE files directly. This is easily the most time- and space-efficient possibility that we discovered, but there's one unfortunate complication that makes it infeasible to use for the time being: it's written in C++. While it's theoretically possible to link against C++ code from GHC, in practice there tend to be a number of obscure linker bugs that arise whenever GHC and C++ mix.

I can't help but think that we're running into some GHC bug(s) that could be fixed upstream, however. This issue serves as a reminder to find out exactly what bug(s) these are and to see if they have been reported upstream.

[RyanGlScott]

I encountered my first issue in https://gitlab.haskell.org/ghc/ghc/-/issues/19350. This arises because the libjimage.so file that ships with the JDK isn't in a path that ld looks for by default (at least, this doesn't appear to be the case on Linux), so you have to specify where it lives with an rpath. Unfortunately, GHCi doesn't appear to use rpaths when loading dynamic libraries at runtime, even though compiled code does, leading to GHC#19350.