Move read queue to a more general "command" queue.

Over the course of testing distributed transactions, I noticed many
unnecessary restarts on SERIALIZABLE transactions due to the fact
that we previously were always updating the range's timestamp cache
as soon as a read or a write command arrived. For reads or writes
which conflict with an ongoing transaction, the update to the timestamp
cache would happen regardless of whether the read or write succeeded.
In many cases, the read or write would fail on the conflict, so the
restart due to advancing timestamp cache ended up being unnecessary.

This change blends both read/write and read-only commands into a
single command queue, which operates similarly to the old read queue,
only now commands always wait on preceding commands which overlap the
same key(s). Read-only commands don't need to wait on other
read-only commands, so we exempt this case for better read concurrency.

This allows us to wait until after the command is executed to update
the timestamp cache, so we can avoid updating the cache on failures.
The odds of a random md5 collision are infinitesimal; I'm worried about the ability of a client to construct deliberate collisions. If the UUID is generated server-side then we should be fine, but if it's client-generated then it's possible for the client to select two keys with colliding md5s (and a common prefix so they end up in the same range) and then append the same UUID.