Implementation of InternalPushTxn operation.

 The details of the op are spelled out in detail in the Range.InternalPushTxn comments and in the
api.proto comments. Unittests provides full code test coverage including
all error conditions.

Changed MVCC.ResolveWriteIntent to no longer accept a Commit parameter.
Instead, we use more of the provided Txn parameter's fields to correctly
update the MVCC metadata / versioned value. The missing piece here was
handling the case of the timestamp being pushed forward instead of just
having the underlying transaction committed or aborted. In the case of
pushing the timestamp, the MVCC metadata txn field is not set to nil,
it's just updated. We also will end up removing the versioned value with
the previous timestamp and create a new one with the updated timestamp.

Cleaned up TODO file.
In this particular case, Txn2, when it updates key "a", it succeeds, but because it's a write/write conflict, "push" in this context means it will abort Txn1, not push its timestamp.

When Txn1 wakes up, it tries to abort Txn2. If Txn2 hasn't committed yet, it'll get aborted. Txn1 will go to commit and discover it's already been aborted as well, so we'd possibly get a mutual abort in this case, but no problem.

I think the confusing thing in the code is the use of the word "push" -- it either means push the timestamp (as for a read/write conflict), or abort the transaction (i.e. push the txn over, as for a write/write conflict).

The heartbeat mechanism allows txns to mutually abort still, but it's a pretty rare case and doesn't affect correctness. I'll rename the "push" variable in the code to "pusher_wins"