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/
Fix file storage admin page not saving (always reverts back to local storage option)

Saving the file attachment storage in the admin would fail, reverting back to
the local storage mechanism. This was because the form was trying to validate
itself but it couldn't because OpenStack Swift fields required no matter which
storage option was chosen. The fix is to set OpenStack Swift fields to be not
required when selecting a storage option that is not OpenStack Swift.

Testing Done:
Tested in Chrome, Firefox and IE:
- Hit save when local storage is chosen -> local storage is selected on refresh.
- Amazon S3 filled out and saved -> Change to OpenStack Swift, leave everything
  blank -> Save -> Navigate away and come back -> Amazon S3 chosen. (Reverse
  Amazon S3 and OpenStack Swift works too).
- Amazon S3 (or OpenStack Swift) filled out and saved -> Change to local
  storage -> Save -> Navigate away and come back -> Local storage chosen.
- Local storage saved -> Change to Amazon S3 (or OpenStack Swift), leave
  everything blank -> Navigate away and come back -> Local storage chosen.
- File attachment uploads to Amazon S3 and local storage works. Unable to test
  with OpenStack Swift since no account available to use.

Reviewed at https://reviews.reviewboard.org/r/6432/
Switch exclusively to server-side Markdown rendering.

When we introduced Markdown support, we had two renderers:
Python-Markdown (for the server side), and marked.js (for the client
side). Due to a number of issues in the marked.js rendering, this
resulted in some unsatisfactory rendered output in certain situations,
and required invasive escaping to work around other issues.

We no longer use marked.js (which will be removed in a separate change).
Instead, Markdown is rendered as part of the page, and as part of any
API responses (by using the force-text-type options in API requests).
This improves the perceived load time of the page, gives us consistency
in rendering, and will allow us to be a lot smarter about how we escape
and process Markdown in the future.

Some behavior has changed along with this, which should help fix cases
reported by users:

* Code blocks without a language identifier are no longer highlighted by
  default, meaning that fenced or idented code blocks can now be used
  for any plain text.

  Unfortunately, this does mean that older text with code blocks will no
  longer be highlighted unless they use a language identifier on a
  fenced code block, but it's worth losing that to gain some
  consistency.

* Text in code blocks will no longer be turned into links, and will no
  longer be syntax-highlighted, making a plain fenced code block immune
  to formatting.

In order to have access to the raw data for the inlineEditors, builtin
fields now have their raw data stored in the reviewRequestData for the
page, and custom fields have their raw data stored as data-raw-value=
attributes (which are then stored in extraData and removed from the
DOM on load).

This change should let us resolve a lot of the issues people have hit,
and provides a stepping stone for proper support for disabling Markdown
for a field.

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