More reliable concurrent schema modifications

Cassandra 2.0 and 2.1 does not like concurrent schema changes (see
https://issues.apache.org/jira/browse/CASSANDRA-8387). Until there is a better
solution in Cassandra itself, make our table creation more reliable by
retrying it a limited number of times. This is safe, as our table creation
code is idempotent.
Release restbase-cassandra v0.3.0
Merge pull request #29 from gwicke/master

Fix table creation issues by retrying & release v0.3.0
Fix query preparation & clean up line breaks somewhat

We used 'prepared' in several places instead of the correct 'prepare', which
means that our queries were not prepared at all.

Also break some over-long lines and detabify index.js.
Fix type errors in tests

Our tests were passing strings instead of buffers in several places, and with
prepared statements those now emit warnings. Fix them.
Merge pull request #30 from gwicke/master

Fix query preparation & type warnings in tests
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
Add Decimal support, fixes #20