Service-scoped tokens and role assignments

This is an evolution of several prior blueprints, including:
- https://blueprints.launchpad.net/keystone/+spec/tenantless-assignments
- https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
- https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition
- https://blueprints.launchpad.net/keystone/+spec/auth-mechanisms-for-services

In addition, this addresses the following bugs:
- https://bugs.launchpad.net/keystone/+bug/968696
- https://bugs.launchpad.net/keystone/+bug/1264325

In summary, the proposal is to replace "unscoped" tokens with explicitly service-scoped tokens (scoped to the identity service itself), and allow users to scope to other services to consume service-specific role assignments.

As a side effect, an "admin" assignment on a project would no longer convey global "admin"ness. This wouldn't break existing deployments unless they also use revised authorization policies which take advantage of the new attributes.

Step 1: Service-based role assignments

- assign roles to users on services
- assign roles to groups on services

Step 2: service-scoped tokens

- unscoped tokens are replaced by tokens explicitly scoped to keystone itself
- allow users to request alternate service scopes during auth

Step 3: revised policy enforcement

(this is out of scope for this bp, but included here to illustrate the roadmap)

- oslo's policy engine needs to be able to enforce service-scoped authorization
- keystone's policy.json needs to be revised to enforce service-scoped authorization