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.
The caller is the range replica handling the client request to read or write which stumbles over a writeIntentError. In those cases, the error contains the offending Txn, which is then used to issue an InternalPushTxn (only by the range replica with the waiting client issues the push--we don't want all three replicas in the case of a write/write conflict all pushing). With failure to push, we return error to waiting client. If push succeeds, send an InternalResolveIntent to Raft, followed by reissuing the read or write that failed.

So yes, we're doing (b). We don't need to issue the InternalResolveIntent through the distributed kv/db instance; we simply add issue the InternalResolveIntent request directly to the Raft instance, followed immediately by reissuing the original read or write command which failed.

I'm going to implement this on the next distributed txn PR! Getting close...