This change does a fairly large cleanup to the JavaScript side of the review

request fields. The old way was pretty hard-coded into the

ReviewRequestEditorView: each of the builtin fields had an entry which defined

some metadata about it, and the editor would scan through those, and then scan

through any remaining fields and pull (more limited) metadata out of the

markup.
With the new model introduced in this change, each (editable) field has a

javascript view of its own which handles its interaction. There are base

classes for the existing types of fields, including plain text fields,

comma-separated multivalue fields, and multiline text fields. By default, each

of the field types defined in fields.py maps to one of these base classes,

which will fall back on the old behavior in order to maintain compatibility

with existing extensions that use them. If those field view types are

subclasses, they can add additional features such as autocomplete or

specialized saving mechanics. There's no longer any special casing between

"built-in" and "other" fields, aside from the fact that the built-in field

views specify useExtraData: false.
While I was in here, I cleaned up several related issues:

- Both the "close description" and "change description" fields used an element

  with the ID #field_changedescription.

- We no longer hard-code #field_changedescription in the CSS.

- Some documentation updates and tweaks.
There's still a lot more cleanup that can be done, moving functionality from

the ReviewRequestEditorModel and ReviewRequestEditorView into the field

classes, but this change seemed like it was big enough already.

Ran unit tests.
Ran js-tests.
Manually tested all fields on the review request page, including rich text

  and CSV-type fields that linkified their values in various ways.
Manually tested an extension that added various field types.