Configurable import resolution

[LightAndLight]

While thinking about package systems in #17, I've decided that the first step should be a way to resolve imports via command line arguments. A more sophisticated package system could be expressed in terms of this simpler interface (but doesn't have to be implemented using it).

Examples

1. ipso --module a=/path/to/file.ipso test.ipso

Meaning: a module named a with the contents of /path/to/file.ipso should be available to test.ipso.

2. ipso --module a.b=/path/to/file.ipso test.ipso

Meaning: a module named a containing a submodule named b which has the contents of /path/to/file.ipso should be available to test.ipso.

3. ipso --module a=/path/to/file1.ipso --module a:b=/path/to/file2.ipso test.ipso

Meaning: a module named a with the contents of /path/to/file1.ipso should be available to test.ipso, and a module named b with the contents of /path/to/file2.ipso should be made available to module a (/path/to/file1.ipso).

4. ipso --module a=/path/to/file1.ipso --module a.b=/path/to/file2.ipso test.ipso

Meaning: the combination of cases 1 and 2, but only succeeds if a (/path/to/file1.ipso) has no definition for named b. If a does define b, then a.b is ambiguous: it refers to both the b definition in a (/path/to/file1.ipso) and the submodule b (/path/to/file2.ipso) in a.

5. ipso --module a:b=/path/to/file2.ipso test.ipso

Meaning: redundant. No module a has been provided, so there is no need to provide a module b to module a.