add InternalSplit command & tests

* added a method CopyInto to the response cache, req'd for initializing a new range during a split.
* added an InternalSplit command. Making the split happen without a transitory period in which things can go wrong is subtle so this needs a good review and likely some changes.
* added some basic tests, but the transition should be bulletproofed using more tests eventually.
Split is actually an exceedingly subtle distributed algorithm. We have to be very careful to get it right. What needs to be balanced here is the correct separation between a distributed transaction conducted by the range leader and the identical Raft commands which must be replayed against the state machines of each range replica.

Let's not worry about this being slow yet. Let's worry about getting it absolutely correct. The two are going to be very difficult to solve simultaneously, although I'm not super worried about performance. This is why we're keeping our ranges in the 32-64M range!

Here's my pseudo code for the actual split algorithm:

On range leader, determine periodically whether a split is
necessary by consulting the estimated size of the range. If
in excess of zone.RangeMaxBytes, initiate split.

Split algorithm from perspective of range leader (this is not
a Raft command, but is done outside of Raft):

  // First, find the split key using a snapshot.
  snap := GetSnapshot()
  splitKey := FindSplitKey(snap)

  // Next, start a distributed transaction to effect split
  // and also update addressing records.
  tx := BeginTransaction()

  // Determine new range ID.
  newRangeID := allocateRangeID()

  // Call split range such that it's submitted as a Raft command;
  // each replica of the range executes it identically.
  reply := db.InternalSplitRange(tx, rangeID, newRangeID, splitKey)

  // Update addressing records for old range and new range.
  updateRangeAddressingRecords(tx, rangeID, reply.rangeDesc)
  updateRangeAddressingRecords(tx, newRangeID, reply.newRangeDesc)

  EndTransaction(tx, true /* Commit */)


Raft command for InternalSplitRange; this is done identically on
each range replica:

  copyResponseCache()
  createNewRange()
  newRangeDesc.StartKey = splitKey
  newRangeDesc.EndKey = rangeDesc.EndKey
  rangeDesc.EndKey = splitKey
  mvcc.Put(tx, KeyLocalRangeMetadataPrefix + rangeID, rangeDesc)
  mvcc.Put(tx, KeyLocalRangeMetadataPrefix + newRangeID, newRangeDesc)

Keep in mind this is just pseudo-code! In any case, the idea here is
that this piece runs as part of the distributed transaction and it
runs on every replica, setting the stage for the split, but not quite
pulling the trigger. The split must be part of the same two-phase
commit as everything else, or we will have problems. Notice that we're
moving the local RangeMetadata value to use MVCC! It currently writes
directly to the engine.

So the question is: how do the KeyLocalRangeMetadataPrefix
"intents" get committed when the the transaction commits? They
don't get automatically resolved by the transaction coordinator,
because their keys are local. However, every Raft command
directed at a range "reads" the key at
KeyLocalRangeMetadataPrefix. If it's an intent, we push the txn
as per usual, which either succeeds or fails. Often times, it
will succeed with already-committed, in which case we resolve the
intent. If we find out the txn is aborted, then the range will clean
up the provisional new range by calling RangeManager.DropRange.