eval, load, and evalAsync: Decide about options.module

[jorendorff]

@samth has proposed that the if you pass {module: "x/y"} as the options argument to loader.eval(), the loader hooks should receive options.referer.name === "x/y" rather than null.

In the browser, effect would be to change how relative module names work in the affected eval code.

@jorendorff is resolutely opposed. eval/evalAsync/load code is not in any module. There is no use case for this and I don't see the generality/completeness argument for it.

[samth]

@dherman says that he likes this but it should be called options.referer or something similar.

[dherman]

(a) We're renaming referer to something else, probably client or importer (b) I don't just like this, I believe it's critical for completeness of the reflection layer: the static system can do a relative import (where normalize uses the importer's name to derelativize), so the dynamic system should be able to as well.

[dherman]

This is important for talking about loading a module, not loading a script; it's usually only going to be important for a module loading a module, where the target is normalized relative to the importer. But you could also imagine in a Node-like situation, where names are normalize as filesystem-relative rather than module-name-relative, even a script doing a relative load of a module makes sense.