Sandbox integration with GraalVM

[sgammon]

When a native-image invocation occurs, there are actually two sandbox/temp roots in play: there is Bazel's sandbox and execroot, and the temp path created by native-image, where it places:

• Generated C code for the Native Image C API
• Built objects / libraries

Native Image's sandbox typically occurs under some directory in the pattern /tmp/SVM-.....

After the compile, native-image copies these back to the output root, where they are surfaced to the Bazel developer. That's how it works now.

However, in more complex circumstances, where a Native Image C API target is using external headers or other resources, the build's posture on disk can be quite confusing: when including a header or some other file, where is it coming from? The Bazel sandbox, or the Native Image sandbox? How does one get files from one sandbox to the other? And so on.

It would be awesome if these rules could integrate Bazel's sandbox with a managed temp path for native-image. This would provide the following benefits:

1. Clear story about accessing resources in Native Image features and directive classes
2. Sandbox hacks can be dropped from the rule internals
3. The full native-image compile state could be inspected in Bazel's sandbox, with files preserved via --sandbox_debug