add store access interface to ranges

For rebalancing operations, stores need to keep track of changes (creation, etc) in the underlying ranges.
Since rebalancing needs to be synchronized through raft, it makes sense to have the bulk of the business logic in the range itself.
That necessitates an interface into the owning store. This is my attempt of providing one that keeps ranges relatively autonomous, makes it easier to initialize a range from a store and also allows the calls into the store to be mocked out completely, which makes for fun testing possibilities.
As for the replica update, below is what's in my head. Are there any obvious gaps?

Let's assume some node wants to transfer a range away from itself to reduce its overall load (all naming below is on the spot).
* it issues an AddReplica request through RAFT and adds a hook that will trigger once there is another replica entering RAFT.
* the leader acks the request immediately (it may chose to deny it if the RAFT log contains a recent AddReplica request that hasn't completed within a reasonable amount of time), not holding up any further operations. Then (maybe in a goroutine) it choses a node and triggers the creation of the new range in an "observer" state (knowing about the existing replicas and receiving new RAFT log entries, but not thinking it's actually already a part of the range). That triggers the transfer from of a snapshot to the new replica, and since the replica now receives all RAFT commands, it will eventually catch up with the rest of the gang.
* Once that happens, the new replica upgrades itself by contacting the current leader who then issues a command through raft that adds the new replica as a full member.
* Now there is one replica more than before. The original replica's hook will fire, and it will destruct itself, announcing its exit through RAFT.