Always use bluebird as the Promise implementation

We are using some of the non-es6 features like .delay() and promisify. Make
sure that those are consistently available even on 0.11.

It also turns out that bluebird is still faster than the built-in Promise
implementation in 0.11 (just re-ran the benchmarks).
Improve table creation retries

On the cluster, schema agreement takes longer than on a single box. In tests
this led to some concurrent table creations failing in the first attempt. This
patch addresses the issue by trying harder & backing off.

- Retry 100 times instead of just 10
- Back off exponentially with a random component
Increase table creation timeout & start retrying a faster

Travis was timing out the table creation test on 0.11. Bump up the limit a
bit, and perhaps complete a bit more quickly by starting the retry quickly.
Merge pull request #32 from gwicke/master

Always use bluebird & longer but gentler retry for table creation
Update dependencies & release v0.3.1
Auto converstion for blob type
Merge pull request #33 from gwicke/master

Update dependencies & release v0.3.1
Merge remote-tracking branch 'hardikj/buffer' into buffer-conversion
Remove identity 'decode' for buffers
Merge pull request #35 from gwicke/buffer-conversion

Buffer conversion
Release restbase-cassandra v0.3.2
Log errors in the cassandra backend

- Pass an options object with log & conf around
- Use the log method for logging of issues
- Don't try to update a secondary index if the primary update failed
Increase the back-off delay on table creation & release v0.3.3

- start with a delay of 100ms
- increase by a factor between 1.5 and 2.5 on each retry
- log any failures
Merge pull request #36 from gwicke/buffer-conversion

Improve error handling & release v0.3.3
Don't replace the global Promise & improve logging slightly
Release restbase-cassandra v0.3.4
Simplify the cassandra client setup

- The connection is now maintained implicitly. There is no need to handle
  reconnecting manually.
- We can use promisifyAll instead of doing this manually.
Release v0.3.5
More aggressive reconnection in the cassandra driver

In load testing I observed at least one worker with connections to only two
out of three cassandra nodes. This worker was clearly not making progress in
its connection with cassandra, and as a result was building up memory despite
only having around 90 client connections associated with it at any time. It
seemed that client connections would time out, but the state associated with
the connection would still remain in memory until the cassandra connection
would clear (which it never did). Other workers on the same node had
connections to all three cassandra nodes, and were making good progress with
little memory used.

This patch attempts to help the situation a bit by at least trying to
reconnect more aggressively. That might have helped that client to
re-establish a connection to the third cassandra node more quickly. I suspect
though that stuck TCP connections are not detected in a speedy manner inside
the cassandra driver. There might be a bug somewhere in there.
Release v0.3.6