Indicate diff size on dashboard

When looking at a list of reviews on the dashboard, it would be nice for reviewers to see an estimate of the workload to do another round. While the red number of unreplied discussions is roughly proportional to reading + replying effort, the red number of files doesn't necessarily relate to the amount of code to look over. We should compute a per-reviewer metric of the amount of code to review for all files since their last reviewed revision and display it on the dashboard.

The metric can be a line-wise diff over all the diffs we'd propose to the user by default. When aggregating commits for review, that's just the default diff; when doing commit-by-commit reviews, it's the sequence of diffs over subsequent revision pairs (and *not* just the one-shot diff between last reviewed and latest). The metric can then be the number of added or changed lines, plus some fraction of deleted lines (since those are usually much easier to review), and ignoring (or discounting) base only and whitespace only changes.

For visual presentation, here are a few potential directions:
- Use the red fill of the unreviewed files level as a vertical bar gauge, spanning from 20% to 100%. This is very compact but low metrics might not be red enough when scanning the dashboard, it might be confused with the deferred state (diagonal red stripe), and it would be inconsistent with the other red labels (esp. discussions).
- Put a small 3/4 donut gauge around the unreviewed files label. Clear and reasonably compact, but will require adjusting the spacing in some layouts so the labels will no longer be evenly spaced, and might not fit well if the label grows to 3+ digits.
- Add an icon (e.g. FontAwesome's gauge) or emoji (e.g., smiling, meh, frowning, scream) after the unreviewed files label. Fairly clear, but breaks label layout symmetry and might be hard to scan. It also quantizes the metric, perhaps more than would be desirable.

Implementation details:
We'd need to compute the metric by running line-level diffs from the dashboard as needed. They could be stored in a per-review file-SHA-pair pool (similar to linemaps and basemaps), and each user would just pick out the ones relevant to their situation.