Multi-project tokens in Identity API v3

Background:
The XML spec for the v2.0 API allows more than 1 tenant (project) per token, but the JSON API & keystone/keystoneclient implementation do not. This blueprint resolves that conflict by specifically allowing multiproject tokens throughout the API, without impacting OpenStack as a whole.

API Impact:
- API support for authenticating with a list of projects instead of a single tenantId/tenantName as seen in v2.0
- API support for returning a list of projects a token applies to on token validation, instead of a single project as currently specified
- API support for remote token validation against a list of projects, e.g. HEAD /tokens?project_ids={tenant_id1},{tenant_id2} (as compared to HEAD /tokens/{token_id}?belongsTo={tenant_id1} in v2.0)

Implementation Impact (openstack services continue to be limited to single-project tokens):
- keystone can raise 501 Not Implemented if it receives an auth request for more than one project.
- auth_token middleware can raise 501 Not Implemented if it receives a token with more than one project.
- keystoneclient must appropriately handle a list of projects for all applicable calls (auth, validation)

This impact of this blueprint is limited to keystone; without the above 501's, the auth_token middleware contract with underlying services would also be required to support multiple projects (a backwards incompatible change), and backwards-compatibility with the v2.0 Admin API could not be maintained (the v2.0 JSON API could not validate a multiproject v3 token via a GET).