qjsc: find module based on path instead of script name

[mochaaP]

Store the original file path in module_loader_opaque, let normalize
function read from that and store a normalized filepath in context
opaque, and make module loader read from the filepath from that.

Make it possible to preserve the custom script name while resolving
from another path.

Split from #1187

[bnoordhuis]

It's not immediately obvious to me what this accomplishes. Or perhaps I should say: it's sort of obvious what it does, but not why (or when) that's useful.

[mochaaP]

Useful if you want to strip the file path from compiled bytecode / make module resolution independent to script name & cwd

Originally qjsc /path/to/script.js -n script.js searches ./, this makes it search /path/to/

[bnoordhuis]

Okay, that makes sense on the face of it. The code in this PR is really fragile-looking though. Maybe there's a way to improve the module loader API to make that easier. What information do you need when?

[mochaaP]

It's possible to remove the Set/GetRuntimeOpaque by making normalize return a struct.
I think setting the module_loader_opaque is unavoidable because otherwise we have to change all Eval interfaces to accept an extra realpath argument.

[bnoordhuis]

A while ago we added versions of JS_Eval and JS_EvalThis that take an extensible struct JSEvalOptions, precisely so we can extend the API without making it too cumbersome to use.

Having said that, I can't really gauge how broadly useful this feature is. I don't want to end up with something that only has a single user. In what real world scenario do you envision using it?

[mochaaP]

I initially wrote this for the meson codegen PR, since run_command cannot specify cwd, and I would like to make generated files the same as make codegen produces.
It's not absolutely required, most of the time this can be replaced by using a slightly more complex directory setup and a wrapper script, but it's a nice addition to have this built-in to qjsc.
since 1. the "build using regenerated sources" option was not merged 2. maintainers always use makefile 3. I have no idea how library consumers can use qjs in what ways, this is optional to have.

[bnoordhuis]

@saghul is a feature like this useful for txiki.js?