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)
> I don't think we should be catching this error here and returning false. If there is an error reaching the redis server, that should be an HTTP 500 error, right?

that's right - these methods worked this way before any unit testing on the `jedis` package. the return value for `verifyResource` was evaluated and an appropriate http status code was then given.

> What is the isEmpty() check for? Is the empty string special for some reason?

this, too, is something left over from pre-unit tested `jedis` package. i was unsure of whether the changes in the `resource` package were relevant to this branch, considering you mentioned that there was already too much here.