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).
Specifically because it requires post-processing in "boot2docker up", but
if we could get "VBoxService" working (or even just "VBoxControl", but in
my testing they both fail in the same way because of the same issues) we
could have that without any extra work by either side, which I'd definitely
be +1 on (and is actually exactly why I wanted to hard lock the share-name
to the inside-the-guest path like I have here, since it makes it easier for
people to set up scenarios like that if they want to).