Fixes webhook, adds fabric script to manage it

This fixes the webhook once and for all, by moving the hookshot daemon's "working directory" out of the `$HOME/hub/current` symlink and into `$HOME`. Previously, the webhook would work for one deploy, but then fail on the _second_ deploy because its previous current working directory had been destroyed.

To reduce the chances of this happening again, I've also adapted the `fabric` tasks from the [18f.gsa.gov deploy process](https://github.com/18F/18f.gsa.gov/tree/staging/deploy), meaning that there's now a `deploy/fabfile.py` in addition to the project's root `fabfile.py`. The new fabric file contains `start`, `stop`, and `restart` tasks for the webhook itself, and makes sure that it's run out of the home directory.

To run these new hookshot fabric tasks, you'll need to have Python 2.7.X activated, and be running `fabric` out of the `deploy/` directory.

Fixes #249.
The `deploy-site.sh` script is basic: it ensures the `foia` user's bash environment is loaded (to make sure the Django environment variables are in place), works out of the current version of the app, turns on the fabric virtualenv, and then runs a deploy **by `ssh`-ing into itself** using the same `fabfile.py` in the root of the project that one of us might run when we do a manual deploy.

These imply some server state:

* A `$HOME/.bashrc` with environment variables.
* A premade virtualenv named `fab` that has Python 2.7.X activated inside it, and `fabric` installed.
* A public/private SSH keypair in `$HOME/.ssh`, where the public key has also been appended to `$HOME/.ssh/authorized_keys`.