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.
Yes.