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 UUID is generated server-side, but the client could ignore it and supply its own txn ID. There are lots of other ways that an adversarial client could muck things up in the keyspace it can write to. The exact same broken guarantees resulting from a duplicate txn ID, could be more simply achieved by not advancing the timestamp between requests, etc. Clients won't munge the system if they're badly behaved; they'll just munge their own guarantees.