Fixed issues saving Markdown data in certain cases.
There were two known bugs with saving data in Markdown.
One was specific to review replies, and was on the JavaScript side of

things. We weren't setting rich_text=true when making requests to the

server, but we had it set client-side. This produced an interesting mix

of Markdown rendering and escaping that was clearly very wrong.

Now we set rich_text= on all requests.
Server-side, we had problems when making an API request setting text

without specifying a rich_text=, when the object server-side already had

rich_text=true set. It would assume all incoming text was going to be in

valid Markdown. That was a problem when updating published review

requests/drafts. It also affected comments, reviews and replies (if done

via the API outside of the Review Board web UI).
For the API, we now have a nice MarkdownFieldsMixin that offers a

centralized function for normalizing fields based on the request data.

It handles the escaping/unescaping of all necessary fields (if passing

rich_text=), as before, and will now also handle escaping provided

fields if the object has rich_text=true and the request doesn't specify

a rich_text=.

Tested running rbt post -g -r <id> after making some changes to a

review request (turning rich text on) and publishing. Previously, my

commit message would be interpreted as valid Markdown, instead of being

escaped. This no longer happened after this change.
Tested replying to a review with Markdown content. The Markdown properly

rendered without being escaped.
Unit tests pass.