Add op tests reproducing issue #417
Split StepsCache out of StepsTranslator into it's own file
Improve navigation speed across StepCache items

The StepsCache is built on the concept that nodes are not re-ordered in
the document during updates. This means the only operations that need to
be supported is adding or removing a node. By maintaining a double
linked list, nearby bookmarks can be very quickly found for any step.
Fix cache-update issue that was causing watchdog overflow errors
Rework how StepsCache responds to step updates to improve robustness

Calculating exact changes in a document can be extremely difficult to
do properly, as such, StepsCache ideally will not rely on them.

In this new approach, modifications to the step cache only require the
last known unmodified step. As iteration across the document occurs,
damaged regions of the cache are repaired and updated, and dead nodes
are removed from the system.

This improves the performance of local edits immensely, at the expense
of "long jump" type operations (e.g., add text then move immediately
to the document end).

Fixes issue #417
Add a cache verification function to ensure cache integrity

Cache integrity checks are very slow, so this should only be enabled
when troubleshooting cache problems.
Ensure damaged bookmarks are never leaked outside of the cache

Converting the cache to a damage-based approach improves the per-update
efficiency immensely, but carries some additional risk as invalid
bookmarks are deliberately left behind for performance reasons.

This patch specifically fixes an issue where bookmarks between the
undamaged step and the current iterator position were being treated as
repaired bookmarks, when in fact they were still damaged (as they had
never been seen during iteration in the document). The new logic will
ensure these bookmarks stay in the damaged region until they are
eventually iterated over in an updateCache call.

A happy side effect of this is that all query functions now only ever
return undamaged bookmarks, making the class itself easier to use and
understand.
Enable StepsCache verification in tests

The StepsCache verification feature verifies the cache after every
modification to ensure it does not contain any bad data. This is quite
slow to do in practice, but is very helpful for debugging, and for
tests.
Modify the damageCacheAfterStep to cope with negative values

If a negative value is passed in as the inflection point to the cache,
it is treated as if it were 0 and the cache is effectively cleared.
Clarified some comments based on PR feedback
Merge pull request #421 from peitschie/delete-roots-fix-2

Rework how StepsCache responds to step updates to improve robustness