Obey command line module order

This is related to #63 I guess although there's a whole bunch of stuff in there.

Currently module order is determined by what goes on in `ENDER.file.flattenDependencyTree()`. The rules are roughly like this I think: add all modules specified on the command line in order except for modules that have dependencies, add those, with their dependencies before them after all modules without dependencies. And so the ordering looks somewhat random but there is a pattern there. (I don't believe ordering has anything to do with async btw).

This is a pain in the butt, you should be able to control module ordering by what you provide on the command line.

There is a second, but related issue which is that the build command isn't kept consistent between build/add/remove/refresh. You end up with dependencies listed as if they were originally specified on the command line, which leads to what looks like further random shuffling (although there is a pattern there too).

Here's some examples:

```
# Example 1
$ ender build backbone bonzo >& /dev/null ; grep 'Build: \|^  provide' ender.js;
  * Build: ender build backbone bonzo
  provide("bonzo", module.exports);
  provide("underscore", module.exports);
  provide("backbone", module.exports);
# Note backbone & underscore go last
$ ender add sel >& /dev/null ; grep 'Build: \|^  provide' ender.js;
  * Build: ender build bonzo underscore backbone sel
  provide("bonzo", module.exports);
  provide("underscore", module.exports);
  provide("backbone", module.exports);
  provide("es5-basic", module.exports);
  provide("sel", module.exports);
# Note 'underscore' now included in the context line
$ ender remove sel >& /dev/null ; grep 'Build: \|^  provide' ender.js;
  * Build: ender build bonzo underscore backbone
  provide("bonzo", module.exports);
  provide("underscore", module.exports);
  provide("backbone", module.exports);

# Example 2
$ ender build sel bonzo reqwest >& /dev/null ; grep 'Build: \|^  provide' ender.js;
  * Build: ender build sel bonzo
  provide("bonzo", module.exports);
  provide("reqwest", module.exports);
  provide("es5-basic", module.exports);
  provide("sel", module.exports);
# Again, the module with a dependency goes last
$ ender add qwery >& /dev/null ; grep 'Build: \|^  provide' ender.js;
  * Build: ender build bonzo es5-basic sel qwery
  provide("bonzo", module.exports);
  provide("reqwest", module.exports);
  provide("qwery", module.exports);
  provide("es5-basic", module.exports);
  provide("sel", module.exports);
# The dependency shows up in the build context line as if we provided it on the command line
```

There's also some apparently random stuff that happens depending on what's currently in your node_modules directory, but that's for another day!

The fix in this PR involves passing the original module list through to `flattenDependencyTree()` and iterate over that list rather than the ordering you get from `tree` (which comes from `constructDependencyTree()`) which is a slightly mangled list when you add in dependencies (there's also that whole JS-doesn't-guarantee-key-order stuff that is effectively moot since all engines do order, but we use an array now anyway).

This has to be done in `build`, `add`, `remove`, and `refresh` where we also have to be careful about what package list we put in the `context` that we send to `ENDER.file.output` because that's what's written to the head and that's where we currently end up with dependencies listed where they shouldn't be.

I've also added in a large test that confirms this works as it should. It's bigger than I'd rather a test be but it seemed appropriate given the style in there currently. I'm more than happy to take suggestions on coding style or about breaking up that test if need be.