On XSnap, switch from using sloppy eval to using the builtin compartment evaluator

[erights]

endojs/endo#31 is an example of a bug we simple cannot fix as long as we're using the eight magic lines of code to safely evaluate. XSnap has compartments whose semantics started us on our compartment semantics. But currently we're not using their builtin compartments yet because of all the semantic gaps on modules and import namespaces that we need to reconcile.

However, those builtin compartments do have per-compartment globals and per-compartment eval and Function that work according to SES rules, which have not drifted. Even though the modules/imports issue mean we still need to build our own compartments or their for now, we could directly use their evaluator for confined execution. This would fix endojs/endo#31 and is really the only practical way to fix it.

[dckc]

It's not obvious to me how we would do this, so I'm adding the design label.

[erights]

See also endojs/endo#730 , which is dup-ish, but we're keeping both open for now.