Rework Back End Authentication and Authorization

# Move `h.auth.local` to `h.accounts`

This module is moved to `h.accounts`. The session-oriented stuff is moved out into `h.session`.

# Move `h.auth` to `h.oauth`

The package no longer has a pyramid `includeme` function. Instead, it is just a library package that exports its public interfaces at its root. These include a `RequestValidator` and `BearerToken` integration for `OAuthLib` and `Annotator`, a `scopes` module (mostly unused for now, see below about authorization), and `client_from_settings` (see next section).

# Move `h.models.Consumer`

The `IConsumerClass` interface is renamed and moved to `IClientClass` inside the `h.oauth` package.

# Drop `pyramid_multiauth`

Introduce `h.authentication` and `h.authorization` modules instead.

The `h.authentication` module has an OAuthPolicy (sub-class of `pyramid.authentication.SessionAuthenticationPolicy`). It checks the session for a user first and then tries to verify the request using `pyramid_oauthlib`. It ensures that the request has `client`, `user` and `scopes` properties.

The `h.authorization` module configures `pyramid_oauthlib` with a client credentials grant type and a default token type. The token type implementation uses the `annotator` module's tokens and the request validator used by both the grant and the token has a bearer token validator using the tokens from `annotator` and the session for implicit client authentication. In the future, we can implement a Pyramid authorization policy here, possible to restrict contexts based on the request scopes.

# Tests

Unit tests are here for all of `h.oauth` and the `h.authentication` policy. No new tests were added for code that just shuffled around, such as `h.session`.

# Migration notes

This changes the name of the Consumer table to Client and switches away from using UUIDs. Since this project is still pre-1.0 we should simply ignore this. A default client is configured automatically and the old consumer table can be safely ignored. Further migration is left as an exercise to the operator, but I don't think really should worry at this stage.
They are weights. They are compared when multiple tokens types are in use to determine which token type is this request. 0 and 9 are numbers that get compared as numbers, not constants. It could be (0, 8) or (2, 6). The important thing is that one is bigger than the other.

OAuthLib actually has a bug here, I think, which I filed a couple weeks ago. https://github.com/idan/oauthlib/issues/299

I wouldn't worry about this now. We only have one token type.