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.
To have CSRF work right we should be passing it two ways.

We could just use the cookie and then send it along in a header as well,
and Angular does this for us by default, but it doesn't for our extension
because it's a third party context, so we make it available in the response
as well.

The Angular devs have said they don't want to add any override to that,
because CSRF isn't meant to be used cross origin, but the extension case is
a bit special.

Soon, we'll be able to do all of this without cookies or CSRF tokens, but
this PR is the prerequisite architecture I want for that.