Add support for merging range addressing records.

This change generalizes the code in UpdateRangeAddressing to support
removing implicated range addressing records instead of just adding
them. UpdateRangeAddressing has been unexported by renaming to
updateRangeAddressing, and its logic better documented and simplified.

The exported methods are SplitRangeAddressing and MergeRangeAddressing.
Split takes left and right. Merge takes the original left and the
updated, merged result of left + right. Merge actually ended up being
simpler than I thought it might be. In effect, you remove any records
associated with the original left side of the merge (remember that
range addressing records are always indexing the END of the range),
and update the new complete range.

The unittest is pretty hairy. It's been rewritten to support both
split and merge and each step takes both left and right ranges.
In the case of split=false (merge), the left range specifies the
original pre-merge left side and the right range specifies the new
merged range. A further complication here is that when split=false,
the left slice of "expected new" meta keys is actually the slice
of meta keys we expect to see removed.
Further simplified logic in updateRangeAddressing
Broadcast EventLeaderElection on all term or leader changes.
Return a channel from MultiRaft.{SubmitCommand,ChangeGroupMembership}.

This channel can be used to wait for the proposed action to be
committed.

Adding this wait to TestMembershipChange demonstrated that the test
wasn't actually doing much. Some of the issues have been fixed
but the test is disabled until we make some decisions about the
group membership protocol.
s/SendMessage/RaftMessage/g

This avoids confusion caused by the fact that the same method name
is used for both the sending and receiving side of the message.
Range scanner which iterates over ranges and adds them to queues.

Next step will be implementation of rangeIterator, integration with
Store, and creation of first actual rangeQueue implementation. Will
probably do garbage collection.
Addressed Ben's feedback; added an empty iteration unittest.
Also fixed data race in the unittest.
move scan interval to a default value and command line flag in store.go
Merge pull request #216 from cockroachdb/spencerkimball/range-scanner

Range scanner which iterates over ranges and adds them to queues.
Rename makeRangeKey to engine.RangeDescriptorKey for clarity
fix test, added more debugging log statements
Merge pull request #212 from cockroachdb/spencerkimball/update-range-addressing

Add support for merging range addressing records.
Add new baseQueue and underlying priority queue code and tests.

baseQueue will be embedded in all range queue implementations.
adjust scanner timing test to be more permissive
Implementation of rangeIterator for store.
Update scanner.go
GC stats to compute likely GC'able bytes from elapsed time.

A GCMetadata record will be written after every GC scan of a range. That,
combined with the current non-live bytes count and current time can be
used to estimate the expected count of GC'able bytes.

This will allow us to avoid constantly scanning ranges which have had no
churn, while using the range stats as well as a detailed picture of the
aging bytes on last GC scan to prioritize ranges for GC.
Address feedback, add unittest, fixed bug in Store.RemoveRange
Address feedback
Merge pull request #218 from cockroachdb/spencerkimball/store-range-iterator

Implementation of rangeIterator for store.