Binary deploy

This is a big change that'll break everything except GCE and Vagrant.  I wanted to fix everything but it is hard to test and this PR is already way too big.

Basically, we are now building and packaging binaries (built in a Docker container) and using these for the deploy.  This means we are no longer installing golang and building source on the worker machines.

Fixes #1351.

After this gets in I'll spawn new bugs to deal with the following issues:
* [ ] Rationalize `build/` directory with `hack/` directory
* [ ] nsinit install is disabled as there is no binary release or vendoring
* Fix cluster deploy scripts for environments that are dependent on our salt scripts
  * [ ] Azure @jeffmendoza 
  * [ ] VSphere @pietern 
  * [ ] Rackspace @doublerr
  * [ ] oVirt @simon3z 
  * [ ] Local @derekwaynecarr 

You can check out a recent binary release here: http://storage.googleapis.com/kubernetes-releases-56726/devel/kubernetes.tar.gz.
Yes -- there are really two things here that were conflated in the old system:

1. Uploading a release so that users can download it.  This is basically making it more automatic so that we can build/upload nightlies and such.  Not need for every cloud to do this and most users won't need it during development (that is why it defaults off).
2. Staging a server config and binaries so that they can be downloaded by VMs/instances/etc at cluster start time. This is different for every cloud.  Some clouds (GCE and Azure) have an object store we can bounce off of while other situations (vagrant, VSphere) can support sharing/uploading to the master via other means.  You can see the upload for *staging* in `cluster/gce/util.sh`.  

The end result is that the user ends up downloading a release to their local machine and then re-uploading it to the object store when deploying.  At some point we can short circuit this and have the deploy refer to the release directly but I'm leaving that for later.