Redis test fixes

This changeset greatly enhances the reliability ( and predictability ) of the redis tests. It also fixes some Future#get deprecation warnings. I'll sweep through and grab the others I noticed in other module tests in another branch. I'll like to get this branch merged first so test failures seen in when others push code don't appear to randomly be breaking the redis module.

A few take aways from this branch that I'll like to impart on others ( and which will probably lead to some related pull reqs from me :) )

- for network service backed stores with multiple tests ( in most cases objects that descend from properties ) be aware that sbt runs tests in parallel, which is great... if your test aren't sharing the same backing store while attempting to store randomly generated keys which can clobber each other! If a given module is susceptible to this, you may which to disable `parallelExecution` in sbt's `Test` scope.

- If your tests require some cleanup, i.e. they make connection to a remote network service. Those connections will likely to stay open, even after a single test run in sbt in an interactive sbt session. It's true! There is a common `close` interface for storehaus Stores but unfortunately scala-check wasn't designed with setup/teardown style tests in mind. However, there's some code in the redis module configuration and test dir that I'd like to extract either into a general storehaus testing module or an sbt plugin ( there's nothing storehaus specific about it ) that handles this for you.

- Lastly, scala-check is awesome. Most of you probably already know this but it's becoming more apparent to me :) Although, some of the default generators are slow because they have little in the way of boundaries for the ranges of data they create. This makes some things hard to predict and to repeat when things fail. You can keep it simple by rolling your own generators. Simple is always best. For me this made the redis tests way faster.