Allow fine-grained setting of rich text modes per-field.

When we introduced Markdown support, we added a single rich_text field
for each supported model, and all fields were tied to that setting.
However, if a person wanted to use Markdown for one field but not
another, they were out of luck. That also required that we perform some
complex escaping/unescaping of all fields on a model when switching text
modes.

This is the first change in a series that splits the rich_text field,
providing per-field flags. The changes are all inter-dependent, but
split up based on layers of the codebase.

This change adds the new rich_text fields, updates logic and templates
to point to the new fields, and removes usage of the old fields.

Reviewed at https://reviews.reviewboard.org/r/6456/
Improve support for fine-grained text types in the API.

This updates the various resources to support fine-grained setting of
text types per-field, to list the text types, and to optionally return
the raw values along with the forced values (if using force-text-type=
and include-raw-text-fields=).

Support for setting text_type= is still allowed on the resources that
have split this field out. It will act as if individual *_text_type=
values were passed. However, the returned text_type value in the payload
is now hard-coded to null.

New text.per_field_text_types and text.can_include_raw_values
capabilities have been added.

This is part of a set of changes to allow for per-field optional for
Markdown. It requires the other set of changes.

Reviewed at https://reviews.reviewboard.org/r/6458/
Backport some of the review dialog Markdown changes from 2.1.

This backports much of the changes made to the review dialog in 2.1 for
Markdown support. Many of the changes made are necessary in 2.0.x as
well.

Primarily, this gives us support for including raw text fields, fetching
comments with a forced text type, and specifying extra query arguments
in drafts.
Add support for raw text fields and text types in JS resource models.

Several JS resource models now have support for fetching raw text fields
and storing them as attributes on the model. This will be used by
Markdown editors to load the raw text for editing while using HTML or
Markdown-escaped for display.

The models can now have includeRawTextFields set to trigger the storage
of the raw fields, which will be stored as the rawTextFields attribute.

Along with this, we now always set the richText fields based on the raw
values, and not the forced values, since we only care about the former.

On top of this, there's also a bug fix for allowing the values in
extraQueryArgs to be overridden for requests.

Reviewed at https://reviews.reviewboard.org/r/6461/
Support handling fine-grained rich text values in the UI.

Now that the models and API support fine-grained rich text values,
the UI needs to be updated to handle those.

With this change, any plain-text fields will be auto-escaped for editing
in Markdown, and will then be saved as Markdown when the user saves the
field. This is the same behavior as before, but operates per-field,
instead of assuming all fields have the same rich text value.

As part of this, the rich text states are now kept solely in the models.
There is no longer a data-rich-text= attribute.

There are some backwards-incompatible changes for extension writers.
Custom fields registered in JavaScript must now use the 'allowMarkdown'
setting instead of 'editMarkdown'. They are also expected to take a
fourth option (called 'fieldOptions') in 'formatter', which must be
passed as an option to 'formatText'.

This change does not yet provide compatibility for custom fields. That
will be covered in another change.

Reviewed at https://reviews.reviewboard.org/r/6462/
Add support for fine-grained rich text for custom fields.

Custom fields now work properly with fine-grained rich text fields.
When loading an old field, the rich text setting won't exist in
extra_data, so we assume rich_text should be true. This is because in
2.0.x, pre-2.0.9, all fields were saved as Markdown by default.

When saving a field, we now set the appropriate rich_text field along
with it, and when loading, we look for that field. We also escape if it
exists and is set to False.

In order to allow setting the rich_text flag, the support for setting
extra_data now attempts to guess the value type. 'true/True/TRUE' will
be interpreted as True, 'false/False/FALSE' as False, integer as
integers, and the rest as strings.

Reviewed at https://reviews.reviewboard.org/r/6463/
Introduce TextEditorView, which supports both Markdown and plain text.

MarkdownEditorView has been renamed and modified to support editing both
Markdown (through CodeMirror) and plain text (through <textarea>). This
edit mode can be set dynamically, allowing a user to choose how whether
a particular field is in rich text mode.

Currently, the default is plain text, which means that when used, all
editors for new objects will show a standard <textarea>. This will
change as I port things over to use the new API.

When placed in an inlineEditor, there will be an "Enable Markdown"
checkbox that the user may check to go in and out of rich text mode.

Reviewed at https://reviews.reviewboard.org/r/6465/
Prepare for conditionally escaping Markdown based on user settings.

Previously, we assumed that plain text should always be Markdown-escaped
for editing purposes. However, when Markdown becomes optional, we won't
always want to do this. Instead, we want to take the user's settings
into account, and only escape if the text isn't already in Markdown and
the user has chosen to edit in Markdown by default.

A couple of new Markdown utility functions were added to normalize text
for editing and for determining if a user wants to edit in Markdown by
default. The latter is hard-coded to True right now.

New template tags have been added for this new normalization. The old
markdown_escape filter has been removed. Templates now contain the
proper edit state for the user.

Reviewed at https://reviews.reviewboard.org/r/6467/
Fix some style-related issue with the Markdown links and fields.

The Markdown reference links were just a bit too high up, which was
more noticeable now that we have a checkbox. This fixes them to be
better aligned.

Plain text fields were also getting a minimum height when they shouldn't
have, due to the way we checked for the presence of a minHeight option.
This resulted in the minHeight being set to the default of 70 when 0 was
passed. We now check for the existence by comparing to undefined.

Reviewed at https://reviews.reviewboard.org/r/6468/
Fix unit test failures with TextEditorView usage.

Some of the unit tests were breaking with the transition to
TextEditorView, in particular with the plain text backend. In some
cases, they were expecting access to methods that no longer existed, or
looking up the wrong data key.

This did expose a real bug in the change event handling, which now looks
for key events as well as change events, and allows the events to bubble
so that key bindings work.

Reviewed at https://reviews.reviewboard.org/r/6470/
Add a session default for rich text, and reflect it in TextEditorView.

UserSession now has a 'defaultUseRichText' flag (currently hard-coded to
true) that indicates if text fields should always default to Markdown
when saving.

If set, TextEditorView will force any text field to be in Markdown mode
initially when open, even if the richText attribute passed to it is
false. This is to keep with the current behavior where plain text fields
(such as those filled in by rbt post) are set to save as Markdown for
any modifications.

(Of course, that only works if the plain text coming in is escaped for
Markdown, which is the responsibility of the caller. A comment above
this new code explains that assumption.)

If the default for the user is not to use Markdown, then the text field
will reflect the provided richText setting.

Reviewed at https://reviews.reviewboard.org/r/6476/
Add utility functions for binding TextEditorViews to elements/models.

TextEditorView now has a set of utility functions for binding various
things in a consistent way.

`bindRichTextAttr()` will cause the TextEditorView's `richText` flag to
be initially set and bound to an attribute on a model. It will not save
out to that attribute, as in practice that's not very useful to us (we
tend to pull data out of the editor when we go to save).

Passing `bindRichText: {model: ..., attrName: ...}` to the constructor
will initiate a `bindRichTextAttr()` automatically.

`bindRichTextCheckbox()` will bind the `richText` flag to a checkbox,
synchronizing state both ways. This is used internally for the
inlineEditor, but will also be used in other locations.

`bindRichTextVisibility()` will bind the `richText` flag to the
visibility of an element. This is also used internally for the Markdown
Reference link, and will be used elsewhere.

Unit tests have been added to cover these cases.

Reviewed at https://reviews.reviewboard.org/r/6477/
Improve JS resource model tests for Markdown support.

This adds some new unit tests to better test the richText values for
some resource models, ensuring that what we pass in will correctly get
serialized for any API calls.

Reviewed at https://reviews.reviewboard.org/r/6478/
Add optional Markdown support to the Review dialog.

This adds checkboxes below the text fields in the Review dialog for
toggling Markdown support. It also loads the correct values from the
API, depending on the user's defaultUseRichText setting in UserSession.

If the default is to use Markdown, the review and comments will be
requested with text normalized to Markdown, and all TextEditorViews will
be set to save as Markdown by default.

If the default is to use plain text, the review and comments will be
requested without any text normalization, allowing the default values to
come in. All TextEditorViews will therefore reflect the stored value.

Toggling the new "Enable Markdown" checkbox for any field will mark that
field as dirty, so that it will be saved when saving or publishing the
review. That will then be saved along with the appropriate Rich Text
setting.

Reviewed at https://reviews.reviewboard.org/r/6483/
Add optional Markdown support for the comment dialog.

The comment dialog now includes an "Enable Markdown" checkbox for
choosing whether the comment should be in Markdown format. The
TextEditorView used will reflect that setting, transitioning between
CodeMirror and a native textarea.

Unit tests have been added to test that functionality works for all the
various states.

Reviewed at https://reviews.reviewboard.org/r/6479/
Merge branch 'release-2.0.x' into markdown-redesign
Merge branch 'release-2.0.x' into markdown-redesign
Add optional Markdown support for the review request page.

This hooks up the remaining bits of the UI on the review request page to
the richText settings. Banners, review request fields, and replies all
now properly load and save properly based on the richText settings.

Most of this is just passing in richText values around, or converting
them to text type values. There are also unit tests to check that the
proper values make it out to the API.

Reviewed at https://reviews.reviewboard.org/r/6487/
Merge branch 'release-2.0.x' into markdown-redesign
Enable per-user defaults for Markdown.

This adds a setting in the My Account page for controlling whether
Markdown is enabled by default. When enabled, all text fields will
default to Markdown mode. When disabled, only fields already set for
rich text in the database will be in Markdown mode by default.

The default for users will be based on the 'default_use_rich_text'
setting in siteconfig. Right now, this is not exposed in the UI, but it
will be in a separate change.

There were a few places left in the codebase where we were assigning
default values for rich_text fields, and those have been removed,
allowing the UI to control the default based on this setting instead.

Reviewed at https://reviews.reviewboard.org/r/6517/