anchor.diff:    Generally, this shouldn't need to be re-implemented;
     however, if the hitchhiker was to be enhanced with key & value size awareness during splits and merges, you'd want to adjust the methods of this protocol.
   
  +`hitchhiker.tree.core/Config`::
  +  This structure must be passed to the `hitchhiker.tree.core/b-tree` constructor, which is the only way to get a new tree.
  +  The `index-b` is the fanout on index nodes; the `data-b` is the key & value fanout on data nodes, and the `op-buf-size` is the the size of the log at each index node.
  +  The internet told me that choosing `sqrt(b)` for the `op-buf-size` and `b-sqrt(b)` for the `index-b` was a good idea, but who knows?
  +
   `hitchhiker.tree.core/IBackend`::
     This protocol implements a backend for the tree.
   +
  
positive.code: 
  - Most inserts are a single append to the root's event log
  - Although there are a linear number of events, nodes are exponentially less likely to overflow the deeper they are in the tree
  - All data needed for a query exists along a path of nodes between the root and a specific leaf node. Since the logs are constant in size, queries still only read log(n) nodes.
  
  Thus we dramatically improve the performance of insertions without hurting the IO cost of queries.
  
  
negative.code: 
  === High-level understanding
  
  The goal of the hitchhiker tree is to wed three things: the query performance of a B+ tree, the write performance of an append-only log, and convenience of a functional, persistent datastructure.
  Let's look at each of these in turn, before looking at how we'll unify them.
  
  ==== B+ trees win at queries
  