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/