Fixes for Vagrantfile

* Give it 1GB memory
* Make sure the broadcast_rpc_address is set to a valid value
Merge branch 'master' into 2.0

* master:
  Fixes for Vagrantfile
Return boolean for successful insert on IF NOT EXISTS
Perform all row modifications in an UPDATE statement

In CQL3.1, anything we want to do to an existing row (besides deleting
the whole thing) can be done as part of an update statement, mostly by
using the `NULL` keyword, as well as the map subtraction syntax. So,
there's no need to use `DELETE` for these operations.

Thus, the `Deleter`'s job is reduced to purely that of deleting entire
rows. Because of this, it's no longer used by `Record` instances or
their collections to track discrete updates.

One pleasant side-effect is that updating a record will now always
happen in a single `UPDATE` statement.
Records don't automatically initiate logged batches

Previously, records would wrap operations in logged batches:

* Running the callback chain
* Issuing the statements needed to update a record's state (possibly
  both an `UPDATE` and a `DELETE`)

The latter is no longer needed at all, since records are updated purely
with an `UPDATE` statement in all cases.

The callback case does make some sense, but unfortunately if we're
running in a logged batch, we can't give immediate feedback on a
duplicate key. To keep things simple, and to get the much bigger
advantage of duplicate key detection, we remove the automatic batching
of callbacks.

No more logged batch for UPDATE query

Also fix a spec that expected a logged batch on create
Some work on key collision detection

Can set key collision behavior to raise an error on duplicate key.
Completely overwrite row
Documentation for key collision support
Allow SomeRecordClass.batch and define SomeRecordClass.in_batch?
Fail if creating in a batch with duplicate key detection

Since batches don't execute synchronously, we can't raise an error at
creation time to give feedback on the success of the operation. So,
don't allow it at all.