Issue 16

this pull request adds a bunch of redis functionality (and the beginnings of a security fix) that will be needed for managing various types of xform data.

the existing setup for persisting data was flawed in that everything was stored as a string at a key in redis which allowed us to retrieve any type of data from any endpoint (retrieving the next unanswered question for a form from the /forms endpoint, for instance)

soon, this will be changed to use hashes with appropriately prefixed keys for each type of resource, example: key `xform-23409234-kjasdflkas-234234` would be a hash containing a field `xml` and the value of the field would be the xform xml document. consumers of the webservice will, of course, _not_ have to specify the appropriate key prefix - requiring them to do so would simply reintroduce the security flaw. so the key prefix has been baked into every endpoint class. an example of this is included in `answersresource` and `formsresource`.

the redis functionality in this pull request consists of @snopoke 's suggestion for standardising the jedisexceptions and jedis command execution, various hash and key functions and method naming changes (many of the methods simply weren't self documenting enough)
We should probably not store anything in redis that doesn't expire -- it's an in-memory database and running out of RAM is easy (and adding more RAM gets expensive fast).

From a practical perspective, humans fulfilling in surveys will likely forget where they were after a few days, so keeping half-filled forms after that doesn't seem like a good idea.

Would definitely be nice to have a configuration setting for the expiring time (and maybe allow it to not expire for people who have special use cases). The configuration setting can be per-server (not per-xform), I think.