build a static cockroach binary...

...and went a bit down the rabbit hole with regards to building a statically
linked deploy docker image. I'm not much of a C/C++ compiling/linking expert
so I absolutely cannot guarantee that everything done here is sane.

There were a couple of road blocks but I ended up getting there (based on
busybox), and in this version we even compile statically linked test binaries
which are run against (but not included in) the deploy image at build time.
The resulting image runs at about 50MB, 45 of which is our binary.
All the tests pass, and you can put this image into `make acceptance` and it
works like a charm.
However, a few nasty things are left over:

* looking up users from the OS will fail on the static image (not sure we're
  using this right now, but that also triggers a warning on each static build)
* building tests statically doesn't work the same way for all of the packages:
  `gossip`, for instance, will still link to libpthread dynamically no matter
  what. Interestingly enough, using CGO_ENABLED=0 and thus the Go linker, it
  will be ok. Since luckily none of those packages actually needs CGO, I was
  able to hack it into the Makefile by rebuilding all offending tests.
  That's certainly not beautiful.
* I have to build with `-tags netgo` to avoid having the binary try to go
  through glibc (or something like that) and not be able to do networking.
  Not sure if that has any (performance?) implications at all.
* Building `testrace` statically will not work. The test harness Go uses
  to make all the magic happen is probably too complex. I think there were
  errors about libpthread again.

Here's roughly what happens in this change:
* rename Docker image: cockroachdb/cockroach -> cockroachdb/cockroach-dev
* new Docker image cockroachdb/cockroach (deployable statically linked)
* vendored in everything that was left: bz2, zlib, protobuf
* build only static libs for vendored dependency
* you can run `make STATIC=1 {build,testbuild}` and get static files
* moved all build-related things into build/
* renamed "deploy" to "run"
* can supply COCKROACH_IMAGE variable to run/local-cluster.sh
* updated the READMEs (hopefully in all relevant places)
make Docker 1.2 happy
CircleCI: build deploy image
address @spencerkimball's comments
CircleCI: add dummy deployment section
Merge remote-tracking branch 'cockroachdb/master' into staticbinary
fix Dockerfile
Update README.md

Added link to slides and to the technical talk presentation at Yelp!.
Fix golint by changing var retryOpts formulation; add a comment to store.CreateRaftGroup
Merge pull request #162 from tschottdorf/staticbinary

build a static cockroach binary
Merge pull request #169 from cockroachdb/spencerkimball/fix-golint

Fix golint by changing var retryOpts formulation; add a comment to store...
update to go tools’ new import paths
build a static cockroach binary...

...and went a bit down the rabbit hole with regards to building a statically
linked deploy docker image. I'm not much of a C/C++ compiling/linking expert
so I absolutely cannot guarantee that everything done here is sane.

There were a couple of road blocks but I ended up getting there (based on
busybox), and in this version we even compile statically linked test binaries
which are run against (but not included in) the deploy image at build time.
The resulting image runs at about 50MB, 45 of which is our binary.
All the tests pass, and you can put this image into `make acceptance` and it
works like a charm.
However, a few nasty things are left over:

* looking up users from the OS will fail on the static image (not sure we're
  using this right now, but that also triggers a warning on each static build)
* building tests statically doesn't work the same way for all of the packages:
  `gossip`, for instance, will still link to libpthread dynamically no matter
  what. Interestingly enough, using CGO_ENABLED=0 and thus the Go linker, it
  will be ok. Since luckily none of those packages actually needs CGO, I was
  able to hack it into the Makefile by rebuilding all offending tests.
  That's certainly not beautiful.
* I have to build with `-tags netgo` to avoid having the binary try to go
  through glibc (or something like that) and not be able to do networking.
  Not sure if that has any (performance?) implications at all.
* Building `testrace` statically will not work. The test harness Go uses
  to make all the magic happen is probably too complex. I think there were
  errors about libpthread again.

Here's roughly what happens in this change:
* rename Docker image: cockroachdb/cockroach -> cockroachdb/cockroach-dev
* new Docker image cockroachdb/cockroach (deployable statically linked)
* vendored in everything that was left: bz2, zlib, protobuf
* build only static libs for vendored dependency
* you can run `make STATIC=1 {build,testbuild}` and get static files
* moved all build-related things into build/
* renamed "deploy" to "run"
* can supply COCKROACH_IMAGE variable to run/local-cluster.sh
* updated the READMEs (hopefully in all relevant places)
make Docker 1.2 happy
CircleCI: build deploy image
address @spencerkimball's comments
CircleCI: add dummy deployment section
fix Dockerfile
Update README.md

Added link to slides and to the technical talk presentation at Yelp!.
Fix golint by changing var retryOpts formulation; add a comment to store.CreateRaftGroup