Mad refactor -- use docker for build isolation, clean up everything in the process

[jfhbrook]

THIS IS READY FOR REVIEW!!

Closes #18 Closes #117 Closes #72

This started out as work to improve isolation/sandboxing of build processes by leveraging docker. This also has the bonus of creating a code seam between the builder (options go in, built bundle comes out) and the bundler (the name of the thing that used to deal with building but now will only deal with caching and options munging).

While docker gets us some nice advantages in terms of build isolation a la chroots, it doesn't give us true sandboxing. Some resources to get us there include https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ and https://github.com/thestinger/playpen . However, while docker currently Just Works on osx, both of these solutions require linux (and a lot more glue code!). Investigation is coming. I'm tempted to ship this to make things better, and then do a phase 2 where I support an alternate sandboxed backend testable on linux/systemd.

While writing the builder I decided to migrate towards promises. This is probably a controversial move. https://www.youtube.com/watch?v=WBupia9oidU That said, it's created some really nice gains around the "don't do 2 of the same build at the same time" problem (look in the build method of the builder), and nodebacks and promises are like oil and water, so here we are! At the very least, I'm doing my best to not write bad promise code. So far so good I think. (Note I don't plan on going apeshit with the promises in the route/controller code, that should remain express-friendly.)

I'm also using es6 classes. Most of the libraries were already implementing class-like patterns, this just makes it more official.

Tests are also happening! This refactor is big enough that I needed to be able to pin some stuff down. This has been particularly nice for dealing with the problem the current codebase has where there's a "pkg" "module" and "version" flying around that may or may not have who knows what properties. The builder enforces specific keys for a number of properties, and these conventions are largely being propagated through the codebase. Tests help ensure the behavior is consistent, and we don't pass a semver into something expecting a version, or vice versa.

Things that are done:

• [x] Fix build script output -- a few boolean values are being shipped as strings, this is avoidable with the right jq flags
• [x] Expose browserify, node and npm versions in build script debug block (before I forget)
• [x] Rewrite of cache cull decorator -- the current code doesn't leverage the cache's existing methods, and uses a really old npm tailing library. (Tailing library appears to still work fine)
• [x] Builder exposed versions should not have prepended v
• [x] Make core module version resolution use correct node version
• [x] Validation for input object (for sanity reasons)
• [x] Tests for builder doing 2 builds for the same thing at the same time
• [x] Organization of web aspects -- views in views, routes in routes, controllers in controllers, middlewares in middlewares
• [x] Change "db" option for cache to "location" or similar (scoped to "level")
• [x] CENTRALIZE RUNTIME OPTIONS! defaults.js is only half way there and there's a ton of ad-hoc env reading in here
• [x] Rejigger travis builds to expose docker https://docs.travis-ci.com/user/docker/
• [x] Figure out why tap test timeouts aren't working (on travis)
• [x] Turn off builder init on app startup, expose on separate tool
• [x] Cache being written to on failed builds o_o (Does docker not proxy status codes?)
• [x] Make cache keys take into account subfiles
• [x] Get existing int tests passing
• [x] Test cases for public scoped modules
• [x] Test cases for requires with subfiles
• [x] Clean up unneeded deps (we should be able to ditch xtend and our bundledDeps, for one)
• [x] Tests for bundler (obviously)
• [x] Pass build information in error messaging
• [x] Get all our logging ducks in a row--a lot of that changed with the build workers
• [x] rejigger the README

Cut scope:

• [ ] Factor fat-ass multi controller into separate lib (not that big, want to replace anyway)
• [ ] Organize view-ish code into actual views (or similar)
• [ ] Render the index page dynamically (exercise-bike is kind of a pain in the butt)
• [x] figure out if I need to pass --name to docker commands (only if you want to refer to the container later)
• [x] figure out how to pass a command timeout to docker commands (not possible, need to write wrapper code that does a ps kill with --name)
• [ ] Test cases for non-latest dist-tags
• [ ] Test cases for views, routes, controllers, middlewares
• [ ] Resolve issues with multiple purge routes (disable "new" routes for now scope out future work later)
• [ ] Closing #70 (will tackle in separate PR)
• [ ] Closing #85 (this might work as a matter of course but is untested)

May this not die in a ditch!

[jfhbrook]

@maxogden This is ready for review. From you, I think I just need some assurances that deploying this won't break requirebin. We should also talk deploy strategy.

[jfhbrook]

Note to self: With https://github.com/thestinger/playpen I should be able to do docker export browserify-builder | tar -x -C sandbox or similar.