Reduce the frequency of DOM scans to rebuild inlines when scrolling revisions

Summary:
Ref T13513. See PHI1734, which raises a concern about the performance of large revisions near the 100-change threshold.

Currently, getInlines() is called whenever the scroll position transitions between two changesets, and it performs a relatively complicated DOM scan to lift inlines out of the document.

This shows up as taking a small but nontrivial amount of time in Firefox profiles and should be safely memoizable.

Test Plan:

• Under Firefox profiling, scrolled through a large revision.
• Before change: getInlines() appeared as the highest-cost thing we're explicitly doing on profiles.
• After change: getInlines() was no longer meaningfully represented on profiles.
• Created inlines, edited inlines, etc. Didn't identify any broken behavior.

Maniphest Tasks: T13513

Differential Revision: https://secure.phabricator.com/D21261