feat: rev-tree per key

[cjqf]

In a recent discussion, the idea of including a CID-based rev-chain at the key-level was dicussed. This is particularly useful for conflict resolution, but comes with some other benefits, such as the ability to "roll-back" specific keys or combinations of keys, etc. There are drawbacks of course, for instance, without some slightly more complicated sync strategies, any two peers syncing a given key will end up pulling the whole history for a key, whether they want it or not. Additionally, tombstones make this sync process slightly more nuanced. In any case, an initial pass with some tests here would be fantastic.

The proposal, as I understand it, would be to:

• Modify the Operation schema type to take a (nullable) prev key which would be of type Link.
• Modify the set and delete methods on kv to include the prev cid reference
  • This would require an additional get that rides on the current transaction
• Modify some of the tests that are expecting a specific number of blocks based on not including the extra links on a type
• Leave everything else "as is" for now, with the new information available as we think through edge cases

I'm certainly missing things here, but at a high level, this seems to cover most of the initial conceptualization