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 ID as is is large-ish, since we suffix a UUID to the first byte key affected by the transaction. It's probably going to be about 100 bytes. Vs. this which is only adding 16 bytes. It'll mean saving a multiple (maybe 2-3x) on the size of this cache, which I expect to be relatively large when summed over all ranges--perhaps 120M with txn ID (assuming system is using transactions heavily) vs. 40-50M with this MD5 of txn ID.

Collisions would be fairly bad. It would mean possibly writing to an earlier timestamp after a reader had read the previous value at a later timestamp. Rewriting history, in other words. But the odds of a collision with a 16 byte md5 digest are infintesimal...like 1 in a billion trillion or something, given the size of the timestamp cache.