The separation of the calculation of the review request page data from

the view provided an opportunity for making more of the page dynamic,

allowing additional content to appear on the review request page. This

change realizes that by introducing a registry that provides the entries

for a page, and making the page data calculation more dynamic based on

the needs of the entry.
ReviewRequestPageEntryRegistry tracks all the entries on the page

(the review request, initial status updates, reviews, and change

descriptions). Extensions could add additional entry types to the

registry, allowing them to show up on the page.
BaseReviewRequestPageEntry subclasse must now specify a unique

entry_type_id, and can specify their data requirements (things like

reviews, file attachments, drafts, and more), along with specifying

whether they should appear before the reviews section ("initial"

entries) or within the main reviews section (the default). These classes

are also now responsible for generating the instances of the entries,

based on page data (including data they compute while building the

entries).
The requirements specified by the entries are used when computing the

data in ReviewRequestPageData. Only the data needed by the entries in

use will be computed. Callers can also specify the specific entry types

they care about when constructing ReviewRequestPageData, which will

help when dynamically reloading parts of the review request page in a

future change.
Unit tests have been added to sanity-check the new entry support and the

dynamic state for the page.

Tested several of the review requests I had here, making sure that the

states and ordering all seemed correct. We'll need more real-world

testing, just to be sure.
Unit tests pass.