The diff viewer was always a little more sluggish than I liked. Part of
this was due to some issues fixed in a recent change involving cache
keys and browser caching, but even with that, we were performing some
expensive operations way before we needed to.

When preparing to render a diff for a file, we generated information
about the file being generated to feed to the DiffRenderer. This
included the chunks (even if we were just fetching from cache). The
DiffRenderer then operated on some of this information in the
constructor. This all happened before we even dealt with determining if
there was a rendered diff already in the cache.

These operations now happen a lot later. We do as little as possible
when asked to render a diff, until we know we're going to actually begin
rendering it from scratch. Only at that point do we request the chunks
from the diff.

This reduces the amount of time for a request considerably. Combined
with the improved caching, it makes expanding a diff nearly
instantaneous, as makes loads for all users (after the first diff
render) very fast.

Browsed a few diffs, with/without server caching primed and with/without

browser caching primed.
Saw some pretty good speed improvements all throughout, particularly once

a diff has been rendered before.
Tested viewing diffs and expanding/collapsing diffs in various areas.