wrap range-spanning ops in txn

added a new OpRequiresTxn error which can be returned if an operation
requires to be carried out in a Txn but is not.
Upon encountering such an error, the txn_coord_sender will re-send
the operation within a transaction.

The way in which this is done currently feels extremely clumsy and
should be improved.

implemented the proto.Combinable interface for InternalResolveIntentResponse,
which can be addressed to ranges.
Hmm, did you consider moving this code to client/kv.go in KV.Call()? That could be a little more graceful since we actually have the client already and so don't need to construct a fake one. This would create a bit of inefficiency for an extra round trip (for non-node clients), as well as more complexity in the client. But on the other hand, this doesn't feel quite right here. Plus this method is already pretty complicated.