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)
This could be a very expensive operation depending on the number of keys. Is it likely that we'll ever need this? If we do think so perhaps it will only be for a subset of keys e.g. all those associated with a particular client / user.

If that is the case we should consider using a set to store relevant keys for a client / user.