collect NodeIDs for ReadWithinUncertainty restarts

the NodeIDs are stored within the Transaction associated to the request.
After having stored a node, future read requests within the same transaction
can set MaxTimestamp = Timestamp in order to prevent uncertainty related
restarts.

Implementing this should considerably impact performance in the relevant case
of transaction reading a busy key from a node with a fast clock, which
otherwise would lead to repeated restarts until MaxTimestamp passes.
no Txn restarts for known "certain" hosts

Building on the last commit, this implements intelligent handling of
MaxTimestamp, taking into account a prior uncertainty related restarts.
In such a case, the host is known to the Txn via its NodeID, and the
request may be carried out with Timestamp = MaxTimestamp, preventing
a further uncertainty related restart
add test for uncertainty restart behaviour

TestUncertaintyRestarts verifies that transactional reads within the
uncertainty interval cause exactly one restart. The test runs a transaction
which attempts to read a single key, but just before that read, a future
version of that key is written directly through the MVCC layer.

Indirectly this tests that the transaction remembers the NodeID of the node
being read from correctly, at least in this simple case. Not remembering the
node would lead to thousands of transaction restarts.

This can easily be tested by disabling that code in the local sender and
running the test.
Simple transaction benchmark

The benchmark runs N transactions back to back, each writing once to the same
key.

I've been seeing a bunch of WriteIntentError related restarts, supposedly
because cleaning up the intents happens asynchronously. This looks like it's
something to expect in such a benchmark to me.

Once Raft is in place, likely the bottleneck will be that.
address @spencerkimball's feedback

notably,
- the range will forward an uncertain read error using the local node's clock,
  as per spencerkimball's comment
- added a test for that
- updated comments in all affected files to point to the proto.Transaction
  comment for details on this somewhat intricate interplay.
Merge pull request #221 from tschottdorf/certainty

improved Txn restart behaviour
Move proto.Transaction to a separation between Key and ID.

Previously, there were two problems involved with concatenating Key & ID.

1. For KeyMin (""), the resulting concatenation wouldn't be directed to
   the first range, but to the range which encompassed the random UUID!

2. Appending the UUID would direct to the incorrect range in cases where
   the range ended before the first character of the UUID. For example.
   For a txn with key "a" and UUID "cccc-..." in range "a"-"b", the
   resulting txn key would be "acccc-...", which would actually end up
   going to the wrong range.