cache: concurrent operation safety, redesign

[dtzWill]

Both StaticBinaryCache and JITCache (since they share much of their implementation)
don't currently take into account safe operation when other ALLVM processes are executing--
it's currently possible for two allready instances (or alley) to perform the same failing check
for cached code, both decide to build it, and then both try to add it to the cache.

A major part of handling this issue is sorting out some of the design details
(such as whether the interface should change to make doing the right thing more straightforward).

As a potential reference I suggest looking at LLVM's LTO Caching code,
such as the bits touched in this recent commit:

llvm-mirror/llvm@91d99c6

---

(maybe the existence of an LTO cache suggests we should be working with them, or at least trying to use their components?)

[dtzWill]

Related: use memfd_create + file sealing to ensure a)cache isn't modified if app tries to write to its image and b)avoid need for filesystem location underlying the fd (and don't leak it)