Use context's globals instead of serializing there

[edemaine]

#1219 was kind of ugly: it serialized the serialize function, parsed it in the comptime context, and then ran it there, so that it could have access to the context's globals.

This PR takes what I think is a cleaner approach: run the serialize in our usual context, but give it access to the comptime context's globalThis and check for matching objects from either globalThis.

In both approaches we have to copy globals over to comptime context, because new contexts don't get the usual Node builtins, such as URL. (See nodejs/node#28823) I'm now doing this in the way that node:repl does, which is better: it gives the comptime context access to important Node globals like fetch, atob, process, etc. This also restores Node's global which seems to be global to all modules, whereas globalThis is local to the module, which makes sense and enables some magic interactions.

// one.js
global.x = 5
require('./two.js')
// two.js
console.log(global.x)  // prints 5

[bbrk24]

Are both ?s necessary? If context is undefined the rest of the chain is skipped.

[edemaine]

Fair point. I think in the future we might want to add more ?s before ::, for both local and remote checks, but given that we currently require that RegExp (say) is present, we can assume that it's also in context, given how we copy over all globals. (I wonder if there are JS runtimes e.g. with no TypedArray support. But we can wait for that to arise.)