Fix performance issue with Cursor
Fix performance issue with Cursor

This patch fixes a number of performance issues with cursors, including
the immediate issue named in #1061, specifically that the `prev` method
was calling `compute_info`.

A deeper underlying problem is that these methods weren't O(log n) in
the worst case. The `next` method was partly fixed by #279, but had a
recursion and so could overflow the stack if the
`next_zero_measure_large` test was increased to `0..30`. The `prev`
method was never improved and had significantly worse performance.

The new strategy for both `prev` and `next` is as follows. First, they
try to find the next boundary in the current leaf. If not found, they
go to the next leaf and try to find the boundary there.

If the boundary is not found in those two leaves, then it is likely that
it is far away. At this point, the strategy shifts to a O(log n)
traversal of the tree to find the measure at the cursor, then another
traversal similar to `descend` to find the leaf containing the desired
boundary.

The logic is simplified a bit compared to #279 because it gives up after
two leaves rather than hunting in the cursor cache for a positive
measure subtree. Doing that would add complexity and improve performance
in cases where boundaries are much sparser than leaves (~1k) but denser
than the extent of the cache (~64k), but degrade performance where they
are even sparser than that. This seemed like a good tradeoff.

Closes #1061

google/xi-editor,google/xi-editor,google/xi-editor,google/xi-editor