refactor(discovery): remove discovery component

This component was used to provide etcd onto a host. Now that we are
using CoreOS as our base distribution which has etcd built in, we no
longer require this component. Going forward, if we decide to run
Deis on a different distribution, we will install etcd on the host.
refactor(contrib): update Deis deployment on AWS

The old contrib scripts used to assist with distributing an AMI with
Deis preconfigured for both the controller and for the nodes across
Amazon EC2 regions. It also helped with spawning a node on EC2
using the controller AMI, then bootstrapped the node so that the
node would be added to Chef. The AMI was meant to help speed up
the bootstrap process, as it pulled the latest Deis components
onto the AMI as well as the Docker daemon along with a couple
other packages.

With the shift to the scheduler, we no longer manage the difference
between controller, proxy and runtime nodes. We let
https://github.com/coreos/fleet do the heavy lifting for us. Instead,
we communicate with a CoreOS cluster and upload a couple of systemd
units onto the cluster. With that shift in thought, we can leverage
Amazon CloudFormation to bootstrap a CoreOS cluster and then do the
rest remotely with fleetctl.
fix(*): make containers host-aware

Before, you had to hardcode the host's IP address and the IP address
to the etcd cluster. Now that we are on CoreOS, we can make some
assumptions about the system, including the default gateway and
where etcd is located.

The host IP address was always accessible through the default gateway,
so there's a change to use netstat to grep for the ip address
of the docker0 bridge. Using that, we can also assume that etcd
is clustered on the host vs. a remote container on some other node,
so we can just use the host IP address and a default port number
to retrieve the endpoint.

We should be using Fleet to manage these containers, so I removed
the dependencies on certain systemd units, since fleet already
considers those units to be running on each host. I also removed
the dependency on deis-builder to be running before deis-controller
can be started. We did this because we wanted to ensure that users
did not run into issues when running a git push, but I feel that it's
a poor decision to kill the controller if the builder is down. By that
argument, we should kill the controller when *any* component comes
down. A `fleetctl list-units` should be more than enough to ensure
that the containers are running as they should be.
fix(contrib): update ec2 cloudformation docs
feat(controller): add container state via FSM

This makes a container's state directly managed via a Finite State
Machine (see http://en.wikipedia.org/wiki/Finite-state_machine).

With this new behaviour, containers can be in one of 5 different
states:

1) up
2) down
3) initialized
4) created
5) destroyed

A diagram that shows the container's transitions as it goes from
state to state would be nice, but is not necessary for this commit.
I've noted this as a TODO feature in the documentation.

I have also set the container's FSM to protected, so that nobody can
directly change the FSM's state. Only a call to the model's functions
that have a @transition decorator will be able to change the state.

fixes #699
refactor(controller): optimize docker build layers
fix(controller): install git

We need git at the moment as a hack to run pip install for
bacongobbler's fork of django-fsm. Once that feature branch
has been merged into upstream, we can remove this hack.
Merge pull request #726 from opdemand/fsm

feat(controller): add container state via FSM
feat(*): add data containers

Some components like the private registry store state inside the
container. It would not be a good day for administrators if the
container restarted, as all of their mission-critical data would
be lost. Adding a bind-mount to a data container lets us restart
the containers without losing this data.

closes #703
docs(scheduler): update documentation for CoreOS/Fleet/cluster changes

Fixes #707.