Merge branch `version-0.0` into `travis-ci`.
Implement split branch.

Closes #6.
Merge branch `split-branch` into `master`.
Rename `keychain` to `designate`.

The function name needs to be a verb, not a noun. The function
determines the key for a branch page or leaf page, which fits loosely
with the definition, "to give name or title to."
Go right first to find parents of pages to merge.

First go right instead of left to find the parent branch page of the
right sibling leaf page of a merge before finding the parent branch page
of the left sibling leaf page of a merge.

We're going to need to keep track of the ancestor branch pages of the
left leaf page of a leaf page merge that have only one child. If a
branch page has only one child, when that child is removed due to the
merge, we will no longer be able to designate a key for that branch
page. Any branch page that would result in having no children as a
result of the merge needs to be removed as part of the merge.

With this commit we take a step toward pruning the tree in this way by
descending to the right before the left, so that we can take note of any
branch pages that would end up with no children. With a list of branch
pages to prune, we can to left and gather a list of their left sibling
branch pages so that we can reassign the right sibling branch page
reference of those pages.

The complexity of maintaining the links between branch page siblings
appears to be greater than the benefits to navigation. The only time
we'll use them is to find the siblings of a branch page to determine if
the branch page can merge with a sibling branch page. The descent to
determine if a branch page can merge precedes a separate descent to
perform the merge.

The preliminary descent does not lock the tree exclusively, nor does it
contend with any descents that would lock a branch page exclusively. The
preliminary descent will therefore not impede the progress of any other
descent. It can hold onto its locks and dive into the tree at any branch
page. If it needs to start from the stop and work its way back down it
can dive into the tree at any point, knowing that it won't deadlock.

In the case where there will be no other descent obtaining an exclusive
lock, shared locks are reentrant, which might simplify the
implementation of the logic to locate the right sibling of a branch
page.
Removed right sibling reference from branch pages.

Removed the reference to the right sibling of a branch page. Branch
pages are no longer linked laterally.
Swappable `unlocker` function in `Descent`.

Added an `unlocker` property to the `Descent` class. The `unlocker`
property is a function that determines whether or not to unlock pages
after they've been visited by the `Descent`. Our merge function will
provide it's own implementation of the `unlocker` function that will
gather branch pages that will be emptied by the merge, holding their
locks.
Merge branch `unlocker` into `merge-branch`.
Delete branch pages empty after leaf merge.

For the leaf page deleted by a leaf page merge, the `mergeLeaves`
function now tracks which ancestor branch pages that would be left empty
when by the deletion. Any branch page on the path to the leaf page with
a single child whose descendants consist only of the leaf page or a
branch page with a single child must be deleted.

After the merge, a branch page such as this will have no leaf page
descendant from which to obtain a key. Somewhere in the b-tree there
will be a branch page with a child for which no key can be designated.

After we find the pivot branch page, we gather up branch pages that
have only one child. We discard the branch pages we've gathered the
moment we encounter a branch page with more than one child. We unlink
all of the gathered pages, if any, as part of the rewrite. We remove the
child on the path to the leaf page from youngest ancestor that has more
than one child. Balancing branch pages continues with the youngest
ancestor that had more than one child.

At this point, however, we're not performing the child removal on the
correct ancestor. The `Descent` class needs to be extended to track the
index used to descend the tree for each branch page so that we know
which child to remove. Currently, we're using the existing logic which
assumes that the penultimate branch page is the page from which a child
is removed to accommodate the merge.
Tidy `Descent` class.

Cleanup the code in the `Descent` class; adjust for the latest in my
preferences for JavaScript formatting, add documentation, and remove
some dead code.
Create `indexes`.
Remove at ancestor, track indexes on descent.

During a merge we now remove the child on the path to the leaf page from
youngest ancestor that has more than one child. In order to know which
child to remove, the `Descent` class now tracks the index of the child
selected by the navigation function for each branch page or leaf page
visited during the descent. This map of page addresses to child indexes
is preserved across forks.
Rename functions within `mergeLeaves` to verbs.

The functions within the `mergeLeaves` function were named with past
tense verbs, indicating the action that had just completed, not the
action that the function is supposed to perform.
Purge cached keys on ghost delete and merge.

Now purging cached keys on the descent to delete a ghosted key or delete
a page by merging it into its left sibling. Just as this has been
implemented, it occurs to me that `designate` is the way it is so that
it will not cache a key when the index is zero. We probably do not need
to perform this purge.

We may want those keys to be cached when we set about merging branches.
A future commit will either reimplement `designate` to cache a key for
the zero index when descending or else remove this cache purging.

Note that, even if `designate` is implemented in terms of itself, and
therefore caches a key for the first child, which is not actually
referenced in the binary search when searching the tree, we will never
cache a zero index key for the path that leads to the left most leaf
page. No care needs to be taken to prevent this from happening, since
we'll never be inspecting these keys during a branch merge, because
we'll never go down that path on a branch merge. It would be unusual if
it managed to happen somehow.
Removed unused variable in `Descent`.

Neglected to remove an unused variable that's been bothering me when I
did the tidy of the `Descent` class a few commits back. Taking care of
that now with this one line change set.
Implement `level` stop function in `Descent`.

Replaced the `descendant` stop function with the `level` stop function
in the `Descent` class. The `level` function will stop at a specific
depth in the b-tree.

The `depth` property of the `Descent` has been exposed through a getter.

The one spot where `descendant` was being used has been updated to use
the `level` function instead.
Implement `lesser` and `greater` in `Descent`.

Created a `lesser` and `greater` property on the `Descent` class. This
property is as of yet unused. It will be used to find the left and right
siblings of a branch page that is a candidate for a merge.

The `lesser` property of a `Descent` is an instance of `Descent` that if
followed to the right to the depth of the owner `Descent` will arrive at
the left sibling of the current page of the owner `Descent`. If the
current page of a `Descent` has no left sibling, then the `lesser`
property is undefined.

The `greater` property of a `Descent` is an instance of `Descent` that
if followed to the left to the depth of the owner `Descent` will arrive
at the left sibling of the current page of the owner `Descent`. If the
current page of a `Descent` has no right sibling, then the `greater`
property is undefined.

The `greater` and `lesser` properties are only known to be meaningful
when descending using a `key` navigation function. It is still
maintained by the `Descent` when using other navigation functions, but
it will not be used nor unit tested except with the `key` navigation
function. Seems that it will work regardless.
Decided against `references` array.

Decided against renaming the addresses array of the branch page and the
positions array of the leaf page so that they both the had a references
array. The documentation became far more verbose as it set out to
describe the meaning of the hopelessly generic term reference.

I documented the decision and removed the todos suggesting the change.
Tidy the `next` function in `designate`.

Making the initial call to the `next` function in the `designate` in a
separate statement, instead of enclosing it in parenthesis and invoking
the parenthetical clause. Consistant with the rest of code. Less fiddly.
Generalized merge function.

Re-implemented `mergeLeaves` using a generalized merge function. This
mean parameterizing the key, the method of determining if we've arrived
at the right page of the merge, and the merge logic itself.

The same function ought to be able to merge branches with the correct
parameters.