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.
Detect key collisions

Record classes can be set to check for duplicate keys using lightweight
transactions, and either raise an error or fail silently rather than
overwriting the record
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.