creating pull request for storehaus-cassandra

Dear Storehaus-reviewer-team,

This is a simple Hector-based Storehaus-wrapper for Cassandra.

The wrapper comprises 3 classes:
1. CassandraKeyValueStore is a simple key-value store with a fixed column (this seems to be similar to the wrapper for Dynamo)
2. CassandraLongStore is similar but uses Cassandra's "counter"-feature to sum up longs, creating interesting effects for put operations (which cannot be done as simple as just putting a value).
3. CassandraCompositeWideColumnStore enables clients to decide which parts of the key should be row-key or column-key by using dynamic composite columns. It requires a Tuple2 with (row-key-list, column-key-list) (so, this is similar to what is being used in the Summingbird-example) and the relevant Cassandra-serializers. This is useful for column-slice-queries.

I ran CassandraKeyValueStore with the Summingbird-example (wordcount). Thereby I noticed the following things:
- swapping in Summingbird might create the need to define 2 Cassandra-Storehaus "stores" in the code as the key and value types are changing which will require to allocate different serializers for row- and column-keys.
- BatchID needs a Long-Serializer-Wrapper serializers in order to be human-readable by cassandra-cli or cqlsh. However, I cannot check this into storehaus as this would require BatchID to be part of storehaus, of course. Can we use some implicit magic?

From my point of view, while reviewing it would be really great if s.o. would consider at least the following things:
- coding style (as i'm new to Scala)
- implementation concepts match the concepts behind Storehaus
- improvements for the serialization mismatch -> can we do s.th. with implicits and how?
- copyright notice (can of course be changed, but you decide, as you will take over legal resposibilities)

Thank you very much in advance!
Regards, Andi
same here and in other places. flatMap the future instead