Add support for using API tokens for authentication.

This introduces new auth and webapi auth backends for performing API
requests using an API token. Users can have zero or more API tokens
linked to their account, and any will be valid for authentication. The
goal is to allow tokens for different access levels (read/write,
read-only) and, down the road, scopes.

Clients can use these when talking to the API by passing
`Authorization: token <token_value>` in the request. This will
authenticate the owner of that token for the API requests.

Tokens cannot be used to authenticate through the website.

For now, tokens must be created through the admin UI. Further changes
are coming to make the usage of tokens more practical.

Reviewed at https://reviews.reviewboard.org/r/6079/
Add web API for working with a user's list of API tokens.

This adds new web API under /users/<username>/api-tokens/ for creating
new tokens, updating existing tokens, getting tokens, and deleting
tokens.

Only the owner of the tokens, and superusers, have any access to these
APIs.

To get the docs to generate correctly, I had to add support for a new
'verbose_name' field, in order for the document title to not turn 'api'
into 'Api'. Some other tweaks also had to be made to handle working with
the session state.

Reviewed at https://reviews.reviewboard.org/r/6080/
Cache lookups of LocalSites in the API unit tests.

We fetch LocalSites quite a lot in the API unit tests. This attempts to
reduce the number of queries by caching and returning them after they've
already been queried once.

Reviewed at https://reviews.reviewboard.org/r/6084/
Add policy enforcement through API tokens.

This allows API tokens to dictate what resources can be accessed and
with what HTTP methods.

WebAPIToken.policy can now contain a set of rules that apply globally
and/or to individual resources, in order to restrict what a client can
access and what HTTP methods they can perform.

Policies are in the following format:

    {
        "resources": {
            "*": {
                "allow": [<list of methods or "*">],
                "block": [<list of methods or "*">]
            },
            "<resource_policy_id>": {
                "*": {
                    "allow": [<list of methods or "*">],
                    "block": [<list of methods or "*">]
                },
                "<resource_id>": {
                    "allow": [<list of methods or "*">],
                    "block": [<list of methods or "*">]
                },
                ...
            },
            ...
        }
    }

Specific resource policy IDs take precedence over the global "*".

The "*" rule belonging to a resource covers all access across the list
and child resource IDs. The ID-specific entries take precedence over the
"*".

Each sub-policy in a resource can have "allow" and/or "block". Each
contains a list of HTTP method names ("POST", "GET", etc.) or a
single item of "*", which means "all methods."

Any attempt to access a resource with an HTTP method that is denied by a
token's policy will result in a PERMISSION_DENIED error.

If a policy is completely empty, the default is to be permissive.

Reviewed at https://reviews.reviewboard.org/r/6091/
Refactor the pre-commit model a bit.

I'm working on making it so "Update Diff" behaves/looks similar to the
pre-commit section of the "New Review Request" page. This change is a
preperatory step: separating the review request creation from the diff
creation. After this change, `RB.PreCommitModel` should be usable when a review
request already exists, by setting the `reviewRequest` attribute.

Testing Done:
Verified that pre-commit review request creation still worked properly with
both single and parent diffs.

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