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

webroot/rsrc/js/application/diff/DiffChangeset.js

@@ -817,11 +817,18 @@ JX.install('DiffChangeset', {
     },
 
     getInlines: function() {
-      this._rebuildAllInlines();
+      if (this._inlines === null) {
+        this._rebuildAllInlines();
+      }
+
       return this._inlines;
     },
 
     _rebuildAllInlines: function() {
+      if (this._inlines === null) {
+        this._inlines = [];
+      }
+
       var rows = JX.DOM.scry(this._node, 'tr');
       var ii;
       for (ii = 0; ii < rows.length; ii++) {