Handful of new module registry edits

[jasnell]

• Disable new module registry for python workers. There are a number of nuances with how python workers are registered and I want to work with @dom96 and @hoodmane to get those worked through. Nothing in python workers would directly depend on or immediately benefit from the new module registry stuff so disabling for now makes the most sense.
• Improve normalization of module names from the user bundle, with tests

Specifically on the second bullet point... All modules provided by the user bundle must remain subordinate to the bundle root (default file:///bundle/), which means if the worker bundle happens to use a name like ../foo, we don't want that module id to be file:///foo, we still want it to be file:///bundle/foo. The handling here to tolerant of silliness. If the name in the worker bundle is something like /.././/./..//.////../../foo, then it'll still be resolved to file:///bundle/foo. Leading whitespace, /s, single-dot, and double dot segments will be removed such that the resolution against the base file:///bundle/ works correctly.

The PR also fixes up handling of the case where the module name is using non-ASCII characters. These will be converted to UTF-8 both in the bundle and in the source and the original handling code was not interpreting those correctly. Tests are added to verify correct handling.

[guybedford]

Thanks for taking on board the feedback and terminology discussion. Depending on how normalizeModuleName is used it might well be a specifier function after all - basically "module specifier" for any string that is at the very beginning of the pipeline and will yet go through every single step of module resolution rules (including possible package mappings / import mappings), while everything else gets named according to where it is in the pipeline helps a lot in ensuring consistent processing.

Because I saw this used for addSyntheticModule, etc. which I'd assumed would apply to at least path-like module names, that's the reason I was wondering if it's not a specifier but rather a path-like -input. Good to have the terminology discussion though anyway.

Just one remaining question otherwise great to land.

[jasnell]

normalizeModuleName is only used when we are building the module registry from the worker bundle. It is not used during module resolution.