This introduces new auth and webapi auth backends for performing API

requests using an API token. Users can have zero or more API tokens

linked to their account, and any will be valid for authentication. The

goal is to allow tokens for different access levels (read/write,

read-only) and, down the road, scopes.
Clients can use these when talking to the API by passing

Authorization: token <token_value> in the request. This will

authenticate the owner of that token for the API requests.
Tokens cannot be used to authenticate through the website.
For now, tokens must be created through the admin UI. Further changes

are coming to make the usage of tokens more practical.

I tested with 2 LocalSites and the global site.
I created three auth tokens: One unbound to a LocalSite, and one bound to each LocalSite.
Using curl, I attempted to access /api/session/ on the global site and on each LocalSite using each token. Results:

Global token could reach the global /api/session/ and that of each LocalSite.
LocalSite token 1 could only reach /s/site1/api/session/, and got a Permission Denied elsewhere.
Same behavior for LocalSite token 2, except it could only reach /s/site2/api/session/.

Specifying an invalid token gave me an authentication error.
Unit tests pass (except that some on master haven't been updated for the function renames, but those are irrelevant to these changes).