WIP on Backend Authentication Refactoring

This PR introduces refactors the back end authentication.

- Separate "clients" and "consumers". Clients are users of the API while consumers are storage domains.
- Support OAuth clients using the client credentials grant, allowing simple, programmatic access to the public stream that is tied to a particular client.*
- Support OAuth clients using JWT Bearer Tokens for OAuth2 as Single Sign On consumers.†
- Remove pyramid_multiauth.

(FUTURE) Return a JWT Authorization Grant, rather than a Cross Site Request Forgery Token, in the response to local authentication requests. Every code path on the front end could then use this grant type and the Annotator Auth plugin (or its future replacement) would no longer require cookies in the token request.

* For instance, we may use this when we introduce rate limiting, setting a harsh rate limit for individual IPs but a looser one for registered clients.

† For comparison, consider other Single Sign On systems. Disqus requires an HMAC-SHA1 assertion[[1]](https://help.disqus.com/customer/portal/articles/236206-integrating-single-sign-on) while Discourse requires an HMAC-SHA256 assertion[[2]](https://meta.discourse.org/t/official-single-sign-on-for-discourse/13045). Disqus uses JSON data for the payload while Discourse uses a form URL-encoded parameter string. JWT neatly encapsulates an algorithm header, a payload, and an HMAC signature in a single, url-safe token, and allows the hash and signature algorithm to change over time. The JWT Bearer Token Grant, an OAuth 2 extension motivated by the need for OpenID Connect to decouple the authentication and token endpoints, provides sensible claims with validation criteria. Using JWT also means developers should be able to use existing libraries to easily integrate Single Sign On.