Internal Intrinsics

[sgammon]

Issue description

When "intrinsics" (what Elide calls built-in VM symbols, often provided by the host VM) are provided to guest scripts, they are always included, even when exposed through internal facade modules.

This isn't super great for a few reasons: (1) they always exist on the global stack, presumably consuming memory etc; (2) user code can see these symbols. Even though they are ugly and unlikely to collide with user symbols, we shouldn't expose these to guest code at all.

Instead, we should devise a way to determine what is "runtime-internal" code that happens to execute as guest code, vs. actual guest code, and make such intrinsics available only where needed and safe.

Node has a similar feature to this in their codebase, referred to as primordials. This object is made available as a VM global only to internal sources. Injection of builtins is simplified by mounting each symbol on a single object.

[darvld]

As part of the experiments accompanying #954, we already have applicable results in this front. Bindings that are only required by guest initialization scripts (e.g. the console object in JavaScript) can be safely removed after the context is initialized. An API for this has already been designed, implemented, and tested.

However, the described behavior only fits initialization scripts, and is not applicable to builtin modules such as those providing the Node.js API. There are two difficult points here:

• Determining whether a GraalVM Source is marked as internal is not as straightforward as it may seem, and in many cases I've been unable to do it entirely, even when explicitly creating a Source object for this intent.
• The guest code that provides the builtin modules runs lazily, the first time it is imported by end-user code. This means that it will not have access to init-time bindings as described above. Additionally, we cannot control how the Source objects corresponding to those modules are created, since the GraalJS module loader API is completely internal (though they have considered opening it in the future).

The two points above mean that, in practice, our own built-in modules are indistinguishable from end-user code when an intrinsic is accessed, which prevents us from implementing internal-only bindings. We must first find a way to correctly identify code that is meant to be internal before we can advance in this direction.