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.