VirtualBox Guest Additions

To provide some context about why this is being reintroduced despite so many expressed reservations, "boot2docker" currently _is_ essentially the "Docker daemon for Mac OS / Windows".  On Mac OS at least, where we have a native Docker client, the experience of talking to your "Docker daemon" currently lacks the ability to bind mount files, which causes a lot of problems including `fig` not working as it should.  This is being pushed as a simple stopgap solution to that specific problem while other more sustainable solutions are developed in Docker itself (such as is proposed in https://github.com/docker/docker/issues/7249).

This builds upon the work in #284.  Also, this includes a hacky init script that @bfirsh gets to take all the credit for that tries to mount `/Users` and/or `/c/Users`, since we can't run `VBoxService` proper (thanks to hairy issues with 32bit userspace of TCL; good times).  The init script will bail quickly and quietly on non-VirtualBox machines or on VirtualBox machines that don't have one of those two shares.

This has been tested on Linux, Mac OS X, and Windows.

If you'd like to test it out without any changes to boot2docker-cli, use:
- Mac OS X: `VBoxManage sharedfolder add boot2docker-vm --name /Users --hostpath /Users --automount`
- Windows: `VBoxManage.exe sharedfolder add boot2docker-vm --name /c/Users --hostpath C:/Users --automount` **(note that this will NOT WORK from inside the msys bash shell because of http://www.mingw.org/wiki/Posix_path_conversion - you must either run it from `cmd` directly, or create the share of `C:\Users` named as `/c/Users` manually)**

This will make it so that things like `docker run -v "$(pwd)":/some/container/path ...` work as you'd expect from Mac OS, and also so that the `/Users` or `/c/Users` directory is available for easy access when you `boot2docker ssh` into your VM.

As a side note, if anyone has ideas for how to disable or prevent that msys path conversion from happening without linking against `msys.dll`, please please please let me know (I can't find anything useful).
So, mostly because I think a solution where we open SSH to instrument the VM after the fact in boot2docker-cli is a really bad hack that relies way too much on the internals of the VM.