Make use of the new web API optimizations in Djblets.

This helps the new optimizations for the Djblets web API code. It calls
the new _get_queryset, and makes use of the new id_field in get_object.
Fix a breakage with interdiffs.

The new interdiff code had a few occasions where it'd miss chunks. It
didn't actually miss them, it just miscategorized as equals.

The reason it did this was that it was attempting to figure out the next
range to consider after figuring out if a chunk was valid, and was only
considering the very next range. What it didn't consider was that there
may be a handful of ranges it should be skipping over that are equal
between the interdiffs, and that it may need to figure this out before
determining if a chunk is valid

This fixes the broken interdiff noticed on
https://reviews.reviewboard.org/r/4257/.

A unit test was added for this case.
Reduce queries for user profiles.

Django's impending removal of get_profile() meant that we had to move to
our own queries for Profile. We ended up using Profile.objects.get and
get_or_create queries elsewhere, but in code paths where a profile was
accessed twice, this resulted in extraneous queries.

User.get_profile is now brought back, and it's under our control. We now
provide our own implementation of this that will survive their removal.
It's more performant in that it doesn't have to attempt an import and
some other logic to get the Profile model, since it can now use the
model directly. get_profile will cache the profile for future lookups.

Profile.objects.get_or_create is aware of the Profile cache, and will
return directly if it's set. It falls back on the standard
get_or_create, and will set the cache on the User before returning. This
means that, unlike how things used to be, subsequent get_or_create calls
will still do at most only one query.
Add API support for the rich_text field on several resources.

rich_text was previously the default for any new objects, and clients
were expected to send text in valid Markdown. This posed a problem for
Review Bot, RBTools, and probably a lot of scripts used in production,
which would suddenly have to know about Markdown.

This change gives clients more control. Now, by default, rich text is an
opt-in thing. It's disabled on new objects by default, but callers can
pass rich_text=true in API calls to indicate that the text fields for
that object should be rich text.

For resources with multiple affected fields, setting rich_text to true
will set the provided text as-is, and escape any text fields not set
during that API call, ensuring their contents won't accidentally be
interpreted as Markdown.

Likewise, if setting rich_text=false, any unspecified text fields will
have any escaping removed, leaving just the text content (meaning that
"**This** is a \*test\*" will turn into "**This** is a *test*").

The web UI always sets rich_text=true in calls. It also ensures that the
text coming in is Markdown, even if it's not stored as Markdown on the
server. That is, if rbt post provides a description for a review
request, then server-side, rich_text will be false, but the web UI will
then escape it when displaying. This ensures that the user will see
Markdown-formatted text and can act appropriately when they go to save
(which will formally set rich_text=true on the server).

Unit tests for the API and UI have been added.
Pull the old djblets sort images into the reviewboard tree.

The reviewboard admin UI uses the sort icons from djblets to indicate the sort.
Unfortunately, when I converted djblets to a spritesheet, this broke. Rather
than try to rearchitect the admin tables to use the spritesheet, I've just
pulled the old images into the reviewboard tree. While I was doing this, I made
it use an icon for descending sorts in addition to ascending, and pulled the
header background image into the reviewboard tree as well.

Testing done:
Viewed the admin UI and set sort orders on a couple different columns. Saw that
I could now see the icons.

Reviewed at https://reviews.reviewboard.org/r/4829/
Fix the API docs generator.

The webapi docs build process was still using the deprecated
allowed_item_mimetypes and allowed_list_mimetypes fields. Update it to use the
consolidated allowed_mimetypes field.

Testing done: Built the API docs.
Reviewed at https://reviews.reviewboard.org/r/4832/
Clarify in the docs that you need to upload full diffs.

When updating an existing review request, some people try to upload just the
incremental diff from their previous change, which doesn't work. Clarify in the
docs how to do this.

Testing done: Built HTML docs.
Reviewed at https://reviews.reviewboard.org/r/4831/
Fixes bug 2899.
Reduce database queries when returning the User list resource.

The User API resource checked profile.is_private on each User being
serialized in a list, which is expensive. Unfortunately, neither
select_related() nor prefetch_related() appear to properly cache reverse
ForeignKey relations, so they don't help us with this.

The best solution, it seems, is to tack on an extra query for our users,
storing the result of Profile.is_private on the User. The
is_profile_visible function checks for this, and attempts to do the
right thing by making use of that value, if it's available.
Fix overzealous escaping of periods when escaping for Markdown.

The period is listed as an escapable character, but it's really only
important after numbers at the beginning of a line. The regexes for
escaping now account for this, and don't escape periods elsewhere.

It's very likely we'll find we want to be even more thorough on some
other escaping, such as parens, but this is the most noticeable one.
Preserve the rich_text setting from the draft when publishing.

The rich_text setting in ReviewRequestDraft was never being set on the
ReviewRequest or on the ChangeDescription. With the new default of
False, any rich text made on a draft would end up being escaped on a
review request, and any escaped content would be double-escaped.
Move the "Extending Review Board" part of the manual up a level.

It doesn't really make sense to have this be part of the "User's Guide", since
ordinary users can't install or enable extensions. This moves the extensions
documentation up one level, to be a sibling of the "Web API Guide"
Show the close description on the diff viewer page.

The close description was only shown on the review request page,
not on the diff viewer page, despite showing the banner. This now
adds the close description there as well.

Fixes bug #2913
Merge branch 'release-1.7.x'
Fix some more style issues with rendered Markdown text.

This fixes the lists to wrap correctly. We're back to native bullet
points, but now things line up correctly. Nested lists also now work,
whereas before they were flat.

The pre-wrap white-space mode has been turned off for all non-code
elements, fixing some other spacing problems.
Show a spinner before rendering markdown text or diff index.

When displaying a review request, there's a brief moment of time before
Markdown gets rendered or before the diff table is loaded where things
look wrong. For the Markdown fields (namely the Description and Testing
Done fields), the raw Markdown is shown first, and then switches to the
rendered text, which looks bad. The diff index shows a big line before
displaying its contents.

These now are marked as loading at first, and we'll show spinners. Once
the page has successfully loaded, the spinners go away and the rendered
content appears.

We also try to render the text for these fields a bit sooner than we did
before, hopefully reducing the load time.
Fix the grip image on the comment dialog.

When we added the jquery-ui stylesheet, and upgraded jquery-ui, it broke
our custom grip image on the comment dialog. That image remained, but an
arrow overlayed it.

This brings it back, and in a cleaner way. We don't add it through
JavaScript anymore. Instead, we just set the CSS rule for that icon.

It now looks as it did in earlier versions.
Set the rich-text info for new replies.

Replies were properly stored as rich-text, but the elements being
created for them didn't represent that, requiring a reload to see the
rendered markdown content. We now set this on the template for replies.
Fix a breakage with the recent close description fix.

The recent close description fix didn't default a variable, breaking the
diff viewer due to a "referenced before assignment" error. This is now
fixed.
Use CodeMirror as the new text field for editing Markdown.

The big problem with Markdown input was that it was too easy to
unintentionally add characters that would render text differently, such
as _, or `. While it wasn't a big deal for things like the review
request description fields, it was a problem for comments, as you
wouldn't know until you published how they look.

To fix this, I've added CodeMirror as a dependency, as integrated it
with all our edit fields. Now, instead of a textarea with just plain
text, there's a syntax-highlighted editor that otherwise behaves just
like a textarea.

CodeMirror itself is hidden behind a new view, MarkdownEditorView. This
is the view used for all text fields now. It provides a convenient way
to integrate in with inlineEditor as well.

All the benefits we had before are still there. CodeMirror does a good
job of feeling native on each platform, and it can autogrow the text
fields to fit the content, just like textarea with autoSizeTextArea.

What it doesn't do is syntax-highlight any code added in the Markdown
text (like Python). It could, but it means adding a bunch of
dependencies for each highlighter, which are bulkier than those in
google-code-prettify (due to also being tokenizers). Even with those
added, it requires an explicit ```language block in order to highlight
them.

It will, however, highlight that they are code blocks, so we have that
at least.
Render markdown fields for HTML emails.

This change adds some slightly questionable code to render markdown to HTML for
the HTML emails. Annoyingly, python markdown doesn't interpret the input quite
the same as marked.js, so some things don't render the same (this is mostly
edge cases, particularly with the treatment of things like whether lists
require a blank line before them or not).

This includes a simple extension for python-markdown that will go through the
resulting element tree and add inline styles. These styles are similar to what
we get from reviews.less, but somewhat simplified.

Testing done:
Viewed the html email previews for review requests, reviews, and replies with
markdown in the review request fields, review body_top/bottom, and comments.
Saw all of the fields rendered to markdown, instead of seeing all the control
and escape characters.

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