The structure of our review request fields were sort of all over the

place. We reused the same class names that sections on the review

request box used, we had a whole separate set of styling and tags for

the details section (which hard-coded a <table>), and we didn't really

have any good places for improving any styling without further

complicating the rats nest of styles we already had.
This change redoes all this, fixing some styles and preparing for

further fixes in the next change.
We have two new review request CSS components:


rb-c-review-request-field: A wrapper for an editable field or

  displayed field value.


rb-c-review-request-fieldset: A collection of fields or other

  content, with an optional label.


All fields make use of these, regardless of presentation. The details

pane no longer uses a <table>, but rather uses a tabular fieldset,

which uses CSS table layout (note that CSS Grid is not an option, since

subgrids aren't widely-supported yet, and those would be needed due to

nested tags).
The fields have a minimum height and line height, ensuring that the page

doesn't jump when going in and out of an inline editor.
The summary field's inline editor now spans the width of the review

request box without triggering wrapping and layout shift like it used

to.
Label information is now provided when registering the fields, which is

fed into the inline editors, helping provide accessible labels.
This change will form the base of the final part of this series of

review request UI work, which will fix various headaches and a

regression we currently have with layout.

Tested this in desktop and mobile modes at different font sizes, making

sure there were no page jumps when going in or out of edit mode for any

inline fields.
Went through the accessibility tree and made sure labels were present

for all the fields and major sections of the review request box.
Unit tests pass.