commit 0c3044bc8bada22db67b93f5760fe3f05d6a5c25
author Graeme Connell <gsconnell@gmail.com> Sun Dec 11 00:56:42 2016 -0700
committer Graeme Connell <gsconnell@gmail.com> Tue Dec 13 09:32:43 2016 -0700
tree b4b695ebcc22e38b8d9dd35c42b3ca5493d1ede0
parent 925471ac9e2131377a91e1595defec898166fe49

O(1) Clone of BTree.

This change allows a BTree user to quickly clone the tree, using copy-on-write
logic to modify shared state.  Both trees continue to reference the original
tree's nodes for reading, thus the clone is O(1).
Writes to either the original or new tree after the clone copy nodes instead
of modifying them.  These operations remain O(logn), but slow down slightly due
to the additional mallocs/copies necessitated by the copy-on-write logic.

Uses a copyOnWriteContext pointer at the tree and node level to determine
which nodes are able to be modified and which are read-only and must be
copied before modification.

To simplify things, freelists have been made safe for concurrent access.
With copy-on-write, keeping track of which freelists are being used by
which btrees is very difficult.  Consider the case:

```go
t1 := New()
t2 := t1.Clone()
```

What freelist should t1 and t2 have?  Can you write to both t1 and t2 at
once?  With this, the answers are "they're sharing one", and "yes".