WIP:  `deis build` as alternative to `git push` workflow

The new `deis build` command is an alternative to the `git push` workflow that allows promotion of existing Docker images, bit-for-bit, into a Deis application.

Note this PR is being submitted as a WIP so we can gather feedback.  Still to do:

 * Ensure documentation is fully updated
 * Research performance implications from extra layer transfers
 * Thoroughly test changes to CLI workflow

# Overview of Changes

 * Controller now includes a Docker-in-Docker engine for processing `deis build` commands outside of an SSH session to the builder
 * New `docker` registry backend for using the Docker-in-Docker engine to build last-mile layers instead of writing directly to a Docker registry -- a tactic deemed bad practice by the Docker core team
 * Refactored logic for creating new releases
 * Client now uses a `~/.deis/apps.yaml` mapping to track applications, falling back to the git remote for backwards-compat (this is necessary for git-less `deis build` process)
 * Builder modified to store `<image>:git-<sha[:8]>` on every `git push`

# How to Test

## Test backwards-compat for existing applications

### Install a Fresh Cluster from Master

 1. Create a Deis cluster on the *master* branch
 2. Register a user with `deis register`
 3. Create a cluster with `deis clusters:create`
 3. Add keys with `deis keys:add`

### Create an Application

 1. Create an application from a git repository (e.g. example-ruby-sinatra)
 2. Deploy the application using `git push`
 3. Commit a minor change to the application and `git push` a new `v3`
 4. Use `curl` or `deis open` to test that the app is up

### Perform an in-place Upgrade

 1. Uninstall Deis with `make uninstall` (should retain database data and application units)
 2. Checkout `deis-build` and use `vagrant rsync` to update code
 3. Install upgraded Deis with `make build && make run`
 4. Use `deis login` to re-establish a session with the controller

### Check Backwards Compatibility

 1. Change directory back into your application
 2. Use `deis info` and `deis open` to check the health of the application
 3. Make a minor change and use `git push deis master` to deploy it
 4. Use `deis open` to confirm it works
 5. Use `deis rollback v2` to roll back to an image created on the old code
 6. Use `deis open` to confirm it works

## Test New Functionality

 1. Create a new directory to hold an application definition: `mkdir /tmp/example-go && cd /tmp/example-go`
 2. Use `deis create` to create an app definition
 3. Use `deis build gabrtv/example-go` to deploy from the Docker Index
 4. Use `deis open` to confirm the app is working
 5. Use `deis config:set POWERED_BY=blah` to confirm config layers are set correctly
 6. Use `deis rollback v2` to confirm rollback works

But I like the `but first, coffee!` string. It sort of defines our application deployment process in a way :)