Add to the types of diff line counts we cache.

Early in 2.0, we began caching the raw insert/delete counts from the
patch file on FileDiffData. We didn't compute the displayed
insert/delete/replace counts because they couldn't be computed at will
without going through a diff generation cycle. They're also more
display-specific, as they depend on the particular diff renderer used,
so they're not a good fit for FileDiffData.

The values we were storing were also a bit expensive to get, since we
had to fetch a DiffFileData for each one. That meant that on the
dashboard, adding the Diff Size column would end up doing 1 query per
row.

Those counts are useful, even if we can't always rely on having them.
We also want all counts closer to avoid the fetches. This change
calculates them at render time and stores them on the FileDiff's
extra_data.

In particular, the following are now stored:

* raw_insert_count
* raw_delete_count
* insert_count
* delete_count
* replace_count
* equal_count
* total_line_count

In the new terminology, the insert/delete counts are for the processed
(rendered) counts, while the raw versions are from the patch.

FileDiff's set_line_counts has been updated to take all those line
counts. Each are optional.

There's also now a get_line_counts that returns all the counts that are
available, and a DiffSet.get_total_line_counts that computes the counts
for all files. For these, there's a guarantee that insert_count,
delete_count, raw_insert_count, and raw_delete_count will be returned.
The rest depend on whether they've been set before.

If the diff hasn't been rendered yet, the non-raw insert/delete counts
will be set to the raw versions. This helps ensure we have at least
something. Callers using those will get the processed versions after
the first render.
Move the FileDiff sorting into its own function.

The FileDiff sorting used when generating the list of files in the diff
viewer was all done inside of get_diff_files(), and the way it was
designed required that we store the base name and base path of each file
in the cache, despite that data never being used after sorting that data
pre-cache.

That logic has now been moved out into a get_sorted_filediffs()
function. This handles the computation of the base name and base path,
which are only computed once per entry (as per the documentation on
sorted()'s key parameter), and are not retained after the sort
operation.

We'll be able to use this function in other places that may need to
represent lists of files.