Use a Docker container to build the site

I'm creating a Docker image that contains all of the build tools and configuration necessary to compile the static site. Hopefully, this can ease some of the pain we've seen lately related to unreliable Vagrant builds.

My goal is for an end user to be able to run `script/preview` and reliably see their local changes in a browser.

This is the first, tiniest tangible part of #974. #976 will obsolete this for most contributors, but this work may help set that up. Also, this will create a certain amount of redundancy in our deployment framework. My intention is to follow this up in a few sprints with modifications to the infrastructure to also use this container in our Jenkins build. I'm also using this to establish some useful conventions for Dockerfile organization and script support.

### Remaining Work

- [x] Jekyll locale issues :rage:
- [x] Automatically open the URL on Macs.
- [x] Investigate live preview. It won't work for the Sphinx parts, but I may be able to get this working for the Jekyll parts.
- [x] Integrate more yak shaving into `script/preview`: probe for and install homebrew and boot2docker if neither are found.
- [x] Mount the Jekyll configuration as a volume, too. We want to use this container for the production builds as well.
 - [x] Take advantage of Jekyll's support for multiple configuration files to refactor the common bits into the container and the different bits into the volume-mounted one.
- [x] Move image building into a different script. Running `script/preview` on its own should just pull from dockerhub.
- [x] Don't run the build as root within the container.
- [x] Write READMEs for the docker/ and docker/build/ directories to document the layout patterns I was going for.
- [x] Change the README instructions.
Why won't you be able to `EXPOSE` the port 4000. I think you should still be able to do that; its only the docker host (boot2docker VM) port that needs to be unique.