Multiple import paths

[squaremo]

• [x] make sure specifiers interpreted as relative paths don't break out of the base path
• [x] allow multiple import paths to be supplied

A natural implication is that if I use -I ~/lib/jk, then a module at ~/lib/jk/foo/index.js can now be imported as 'import f from 'foo'.

This deserves some elaboration. Prior to this PR, the effective module resolution rules were something like

• if specifier is @jkcfg/std[/something] or a "magic" import, load from the runtime
• otherwise:
  • (a) try treating it as a path relative to the importing module (or script being run, or $PWD)
  • (b) try treating it as a NPM module

The resolution (a) was done both by FileImporter and NodeImporter, in nearly the same way. The only case which FileImporter covered which NodeImporter didn't was referring to a relative path without using ./ or ../.

But this wasn't suitable for the expected behaviour quoted above, since the FileImporter would never attempt to resolve relative to its own root path. So I have changed it to treat explicitly relative paths as relative, and other paths as based at its root.

There's good evidence that this will not cause too many problems:

1. this is how NPM resolution (that implemented in Node.JS, and that implemented here) behaves already
2. only one test broke from having a relative path that was not explicitly relative

[squaremo]

I'm going to close this, because #307 is a better basis for this extension, so it will have to be reworked.