Use fig instead of dockerBuild.php.

dockerBuild.php was a hack I put together just to test out how
orchestrating the separate containers would be.  Turns out, this is a
problem that needs more than a simple hack to solve.  The root of the
issue comes down to the edge cases where the state of various containers
isn't being properly handled: it tries to run containers that already
exist in some cases and doesn't run ones that have been stopped in
others.

Rather than beefing dockerBuild.php out into a larger script to handle
all this (complicated!), I took a look around to see what is on offer:

* [fig](http://fig.sh) - nice and simple and built to solve this exact
  problem
* [kubernetes](https://github.com/GoogleCloudPlatform/kubernetes) -
  Potentially useful in a production environment, but a bit overkill for
  our problem.
* [fleet](https://github.com/coreos/fleet) - Very interesting, but the
  ties to systemd and etcd make it difficult to use in all environments.
* [ansible](http://docs.ansible.com/docker_module.html) - A nice
  chef-esque way of doing things, but requires a lot of extra
  configuration to manage and feels funny running against localhost.

All in all, I couldn't find much out there to really compete with fig
for this usecase although I'm sure some other small attempts exist.  fig
is a python-based command, but it is distributed as a linux binary, so
python doesn't really come into play.  It takes 30 seconds to setup and
has a very intuitive CLI (coming from Docker) with decent documentation
via `fig help <command>` and via its website.

Implementing the switch is fairly straightforward.  Take the primary
docker run line and extract the links and volumes into the fig.yml
configuration as given.  Create a "build" image that is the primary
build for the package.  Additional services can also be added (mongo,
redis, etc.) and because they are linked to the "build" image, they will
be started first before the build container is run.

The set-env.sh change is related to a small difference in how fig names
its containers compared to how dockerBuild.php does.  It takes a more
convention-driven approach that allows for multiple copies of a single
service and doesn't provide configuration for overriding its service
names (that I can tell).
Move the Dockerfile to tests.

In practice, docker only allows a single Dockerfile per directory.  This
makes the directory that the Dockerfile is in analogous to a namespace
for your container.  It's important to place these containers in the
correct location.  In this case, I believe that this Dockerfile belongs
in the tests namespace and that we should keep the root project
namespace open for something that potentially "executes" the project in
a more general sense.
Merge pull request #4 from nubs/master

Use fig instead of dockerBuild.php.
Rebase the Dockerfile off of nubs/phpunit.

nubs/phpunit (and its parent nubs/composer-build) provide a much better
base for our build docker images.  They ensure that the build isn't run
as root, setup a more sane environment (with open_basedir restrictions,
correct environment variables, fully operational composer, etc.), and
handle abstracting out the core composer and phpunit dependencies.

This also moves the `set-env.sh` script into `/home/build`.  That
doesn't require root to create or execute, so it should belong to the
build user.
Merge pull request #5 from nubs/master

Rebase the Dockerfile off of nubs/phpunit.