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.