Keep layout from looping and the scroll offset from leaving its range

[koldoon]

What this fixes

_updateDisplayRenderParagraphs calls itself when layout has corrected the
scroll offset, and that recursion has no limit. It does not always converge:
applyContentDimensions starts a ballistic activity while the offset is out of
range, the activity moves the offset, and the next cycle sees the same mismatch.

Two failures our users hit, both taken from a running process rather than
guessed:

• The application froze hard after a few PageUp/PageDown presses. The
  stack pulled from the VM service was thousands of frames of this one method.
• The editor shuddered at the top of the file. The offset sat a fraction of
  a point above zero (we logged −0.7), layout kept asking for layout, and the
  ballistic activity that would have returned the offset to zero was restarted
  by every frame and never got to run.

The change

• The number of layout cycles is bounded, the way RenderViewport bounds itself
  with _maxLayoutCycles. The estimate behind the recursion cannot be made
  exact — lines outside the viewport are counted as one grid line each, while a
  wrapped line takes more — so it needs a bound rather than a better guess.
  Stopping early costs at most one imprecise frame.
• The rebuild is skipped when there is nothing above to build: if line 0 is
  already the first one shown, rebuilding cannot close a gap at the top.
• makePositionVisible no longer leaves the scrollable range, and the distance
  to a line below the viewport is counted from the last displayed line rather
  than the first — counting from first overshot by a whole screen. Landing out
  of range is what hands the offset to the spring simulation in the first place.

Found while building a file manager on re_editor.

---

Related: #122 — that one removes the source of the accumulating correction. This one keeps layout terminating whatever the estimate, since with word wrap the estimate cannot be exact.