Remove last use of gjs_runtime_get_context, and remove the hook
runtime: Have a thread-specific JSRuntime

JSRuntime needs to match 1:1 to a thread, so if we have more than
one runtime in a thread, like we did in the test suite before, we
would blow up.
ns: Add gjs_import_gi_module

This returns the bare module, and doesn't run overrides or anything like
that yet... that will have to wait until after we get our new importer
scheme working...
Add a bootstrap system, allowing us to write JS code at early boot

This will be used to write a CommonJS style imports system for JS,
but it could also be used for other things, like rewriting window.log,
window.logError, etc. in JS.
jsapi-util: Add a gjs_parse_call_args variant, that takes JS::CallArgs

JS::CallArgs is now a recommended replacement for the argc/vp pair, and
in the future, JSNative will take a JS::CallArgs directly, instead of a
argc/vp pair. For now, use the semi-deprecated "array" member to share
the same code as the old argc/vp interface.

When upstream deprecates argc/vp, we'll port everything to JS::CallArgs.

This is because I spend almost half an hour finding a bug with the old
interface (I called JS_SET_RVAL on the argv instead of vp), and they
recommended that I use JS::CallArgs instead.
native: Return NULL if the module isn't registered

This can't ever happen in practice, since existing callers check
gjs_is_registered_native_module, but with our new loader, it's a
bit more convenient to simply check against NULL rather than have
to do a precheck or catch an exception first.
bootstrap: Add a CommonJS-style imports system

Use a native JS hook to add an implementation of the CommonJS Modules
1.1.1 specification, using require(). This is independent from the
existing imports system.

This implementation has one minor deviation from the spec to be more
compatible with the old imports system, and that is that modules are
not run in their own private namespace, but instead directly in their
"exports" namespace. That is, "this" and "exports" are the same object
within the module. The "module" variable is also on "exports".
This means that we can port the majority of modules over without
requiring that they be rewritten to use exports, which doesn't exist
in old versions of gjs.

The existing imports system is considered deprecated, and will soon
be rewritten as a compatibility layer in JS.
import compat