Drastically reduce the number of queries made in the dashboard.

Our dashboard started out simple, with minimal queries, but as we added
new columns we introduced a number of fairly expensive queries that
operated on each review request individually. This ballooned up to a
worst case of a few hundred queries in a full dashboard. The worst
offenders are columns that are pretty common in most dashboards.

This change cleans up our queries by removing or reducing the individual
queries in most cells.

The ReviewRequest manager methods (public, to_user, etc.) now take an
optional with_counts parameter that, when True, will perform several
extra queries as part of the query for the review requests to return the
counts that we care about. This makes for a more complex query (though
not a very expensive one, especially in comparison), but reduces our
query count by 5 or so queries per review request (depending on column
configuration and such).

The query count for the New Updates column has been reduced from 4
possible queries down to 1, saving another 3 per review request.

Also, the logic for ReviewRequest.get_new_reviews was performing one
more query than it needed. It was getting the count and THEN getting the
first object. We really just wanted that first object. This may reduce
the query count for some parts of the codebase, but the dashboard no
longer uses this function.

So in total, on a full dashboard with 30 rows and all our expensive
columns, we should save upwards of 240 queries, hopefully speeding up
the dashboard quite a lot and reducing stress on the database.