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.

All new and existing unit tests pass.
I created a couple tokens to play with. I tested global blocking of the API, per-resource blocking, per-ID blocking. I also tested blocking with per-resource and per-ID allow.