Add support for globalLexicals

[kriskowal]

The motivation for this change is for metering, which is related to coverage analysis instrumentation.

In coverage analysis instrumentation, compartments need:

1. a global that can capture coverage information
2. a transform that converts every expression into an equivalent expression that also notes coverage information.

For example, the expression value would be transformed to (coverage._x0fd++, value), where the arbitrary key _x0fd uniquely identifies the expression.

For coverage analysis, we might not be worried about user code “attacking” their coverage analysis, so adding coverage to globalThis is sufficient. However, user code could alter its coverage results by including the statement coverage._x0fd = 1e10, for example.

The coverage tooling can censor the word coverage, throwing an exception if the user code includes this word anywhere. This would even frustrate user code that attempted to reach for coverage through computing an evaluated string, likee (0, eval("cov" + "er" + "age")), because within the compartment, the argument to eval is itself user code subject to all the compartment’s transforms.

This is not sufficient because user code can still compute properties of globalThis, like globalThis["cov" + "er" + "age"]. A transform that virtualizes all computed properties would be impractically slow. So, instead, we propose that the Compartment constructor accept a globalLexicals option. The global lexicals would exist in a scope that overshadows globalThis but cannot be named in that scope. By using globalLexicals instead of globalThis, banning the word “coverage” is sufficient to prevent user code from manipulating this special register.

The compartment constructor must capture a snapshot of the given global lexicals and present these as constants in the scope of all modules and all evaluated code. Changes to the given global lexicals should not be observable. An accessor property on a global lexical must be called exactly once in the scope of the constructor.

This proposal bears a resemblance to the concept hitherto named “global contour” #34. Ideally global lexicals and the global contour could be reconciled into a single feature, though that requires reconciling the immutability of global lexicals with the mutability of the global contour, and that the global contour must be manipulated by evaluated code should not be observable in modules.

[Jack-Works]

Does it mean when lookup a reference, it will go through this order?

globalThis < (not accessible ) globalLexicals < local scope