Submodules are brittle

[Paul Jimenez]

Using the code in the repo as an example, it's plain to see that the current implementation of submodules is brittle.
In the repo, build.vel imports scripts/dist.vel. scripts/dist.vel has a bunch of references to dist.* ; this is wrong - they should be local references to the local namespace - if dist.vel was imported as some other name, they'd be wrong.

Ronny and I chatted on IRC about it and came up with:

22:04 < ronny> module.options -> options.module, module.targets -> targets.module
22:05 < ronny> ie if you import something as mymodule
22:05 < ronny> you will get a mymodule element in options and a mymodule element in targets
22:05 < ronny> oh, and in depends of course

So 'import' becomes a way to reserve a name in all three sections for a sub-namespace.

Note that this sub-namespace is writable from the importer. So while the existing dist says:
# requires that you have options: setup, project, website, vesion, and sudo

instead you would import dist and then in your options do
  dist.setup "your setup value"
  dist.project "your project value"
  dist.website "http://whatever"
...and etc.

This keeps the submodule self-contained; someone using it doesn't have to tweak it or change it - I can see eventually shipping a set of standard recipes so that a build.vel becomes an import and some options and not much else!

One tricky bit will be flattening the options with all the overrides correct; this will have to be done so they can be put into the py locals() and the sh environ.

Other random thoughts:
 * invoking target 'submodule' should invoke the submodule's default target.
 * the sub-namespaces need to be *copies*, because I might import the same module multiple times each as a different name, and then set their options all different. Consider some project that uses distutils on multiple parts - you want to use the dist module on each part, but with different options. Copy-on-write eventually maybe, but RAM is cheap so go for reliable first.
 * This all falls out of the Zen of Python: "Namespaces are one honking great idea -- let's do more of those!"