URLs for serving images on the frontend

This pull request makes it possible to generate images on the fly with urls like ```http://mysite.com/images/<security key>/100/width-800/```.

Format of the URL: ```/images/<security key>/<image id>/<filter spec>/```

The ``filter spec`` parameter is the exact same used in the ```{% image %}``` tag described here: http://wagtail.readthedocs.org/en/latest/building_your_site/frontenddevelopers.html#images-tag

TODO:
 - [x] Implement HMAC authentication (https://github.com/thumbor/thumbor/wiki/Security)
 - [x] URL generator in admin
 - [x] Set correct cache headers in serve view
 - [x] Tests
 - [x] Docs
It's not absolutely guaranteed that a Wagtail install will have a site with `is_default_site=True` - it might just have one or more sites responding on specific domains. We should catch Site.DoesNotExist here, and fall back on Site.objects.first(). (This might actually be the only place in Wagtail where we assume the existence of *any* site records at all, but that's a fairly theoretical concern :-) )

Also, on my dev instance the preview image is currently a broken link, because I haven't bothered to go in to the Sites record and fix the port number. This is probably going to be a common occurrence, because I don't think there's anything in the setup docs to tell people to fix that - and in general Wagtail is designed to sidestep the issue by avoiding full URLs unless absolutely necessary, so that things work out-of-the-box as far as possible. With that in mind, I would suggest that the JSON response here returns both a full URL and a local one, and the latter is used for the preview image. Obviously the displayed URL has to be the full one, and if the site record is misconfigured then that's going to return http://localhost/images/blah rather than http://localhost:8111/images/blah - there's not a lot we can do about that - but that's acceptable I think, since it's a lot more obvious what the problem is.