Allow specifying ?force-text-type=html to Markdown-capable API resources.

Many of our resources support passing ?force-text-type=plain|markdown to
convert to either plain text or Markdown format. Now, these also support
"html" to render to HTML.

This is the first step to moving entirely to server-side rendering of
Markdown content.

Reviewed at https://reviews.reviewboard.org/r/6406/
Support Markdown in the Submitted/Discarded text fields.

We didn't have any proper support for Markdown text in the
Submitted/Discarded text fields before, due to lack of proper plumbing
in the API and in ReviewRequest.close().

Now it's possible to write Markdown and save it. It will render both in
the banner and in the change description box.

Reviewed at https://reviews.reviewboard.org/r/6409/
Improve close description support in the API.

The review request resource now has a 'close_description' field that
will be set to the close description text, if provided and if closed.
This makes it easier to see the status of a review request without
digging into other resources.

This also deprecates the 'description' field when closing a review
request through the API. The new argument is 'close_description', which
matches the returned value and doesn't conflict with the field.

Reviewed at https://reviews.reviewboard.org/r/6412/
Allow custom arguments to be passed for reply comment requests.

This updates the reply comment resources to allow for unknown arguments
without triggering validation errors. We need this in order to use
fields like force_text_type (for now) and extra_data.

This matches the behavior of other comment resources.

Reviewed at https://reviews.reviewboard.org/r/6418/
Allow force-text-type= to apply to custom fields in extra_data.

Review request and draft API resources now show custom review request
text field values in the requested text type, matching the behavior of
the description, testing_done, etc. fields.

This is done by having MarkdownFieldsMixin own the
serialize_extra_data_field function. It then asks the specific API
resource class to determine if a given field in extra_data supports
Markdown. If so, that field's text will be normalized.

ReviewRequestResource and ReviewRequestDraftResource both provide this
function and check the given field to see if it's Markdown-capable.

Reviewed at https://reviews.reviewboard.org/r/6420/
Support sending force_text_type= in POST requests.

POST requests now support force_text_type=, in order to force the text
to be of a certain type. This mirrors the ?force-text-type= argument in
GET requests.

The resources that support this have been updated to take this argument
in their supported field lists.

The "html" text type is also no longer set as saveable.

Reviewed at https://reviews.reviewboard.org/r/6421/
Turn off guessing of languages in Markdown code blocks.

We previously used Python-Markdown's default behavior of guessing
the language based on the contents of the code. This was often wrong, or
didn't result in anything meaningful. Fortunately, that almost never
came up in usage (since we were using marked.js and
google-code-highlight for the rendering), but when we move to
server-side-only rendering of Markdown content, it'll become more
important.

Now, syntax highlighting is only enabled if using fenced code blocks
with a language specified.

The manual has been updated for these changes.

Reviewed at https://reviews.reviewboard.org/r/6422/
Use the new close_description field when working with close descriptions.

Now that we have a new, improved field for specifying close descriptions
on a review request, it's time to make use of it in the UI, along with
cleaning up the code surrounding it.

The code dealing with "changeDescription" has been split up a bit to
work with either "changeDescription" or "closeDescription," and to look
in the ReviewRequest or DraftReviewRequest, depending on the field.

This also helps set up for bits of the new server-side Markdown change.

Reviewed at https://reviews.reviewboard.org/r/6424/
Change the function signature for RB.formatText to accept options.

RB.formatText will be taking a slightly different role in the Markdown
changes. In preparation, and to keep the code future-proof, it now takes
an options attribute instead of the options being passed as positional
arguments.

Reviewed at https://reviews.reviewboard.org/r/6425/
Fix home/end behavior in CodeMirror.

By default, CodeMirror makes the home and end keys navigate to the beginning
and end of the line of text, regardless of how it is wrapped. This is different
from the usual behavior of text fields, where if the text is wrapped, home/end
go to the ends of the wrapped line (i.e. the cursor stays on the same visible
line within the wrapped text).

Luckily, there's a pretty simple fix for this, as detailed at
https://github.com/codemirror/CodeMirror/issues/1576

Testing done:
Added some long-form text to an open CodeMirror editor and checked that
home/end now behaved as expected.

Fixes bug 3392.

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