support domain scoped user project domain rbac

Summary
=======
Keystone v3 has supported multi-domain configurations since Grizzly. Horizon needs to add support for domain scoped tokens and their use to expose this functionality.

Motivation
==========
Keystone v3 supports multi-domain configurations. Part of the motivation of domains is being able to enable compartmentalization of resources. To make full use of this isolation, it's desirable to provide users administrative rights over just one domain, but not the whole stack. A finer granularity of roles is required to do this. For example, an administrator over an individual domain should be able to add new users, create projects and assign roles to users inside the domain they administer. To support these actions Horizon needs to support maintaining domain scoped tokens which are required to complete these actions and use them in the appropriate situations.

Description
=========
In a pre-requisite blueprint, django_openstack_auth will manage obtaining and storing the domain scoped token on the session where the configuration necessitates it. There are three use cases handled when domain scoped tokens are involved.
1) The user only has a role on the domain.
   -- In this case, the user will log in and obtain only a domain scoped token. There will be no other services in the user's service catalog and they will only have visibility to the Identity dashboard. Their access to read/update in that dashboard will be determined by RBAC.
2) The user has a role on the domain and a project(s) in that domain
   -- In this case, the user log in and obtain two tokens, both are stored on the session.
     * For the identity dashboard, the domain scoped token is used to make API calls. Their access to read/update in that dashboard will be determined by RBAC.
    * For the other dashboards, the project scoped token is used to make API calls to all services.
3) The user has only a role on a project(s) in a domain
   -- In this case, Horizon behaves as it does today.

Additional work will need to be done to make sure that richer policy files [2] are supported in the Identity dashboard.

UX
===
The nature of this change is wiring in Horizon. The end user experience should be unaffected other than enabling Identity management at the domain level when using a richer policy file [2]. All views already exist.

Wireframes, Mocks, Videos and UI Markup
---------------------------------------------------------
N/A

Testing
======
In order to test these changes, there are a couple of settings changes required in local/local_settings.py

OPENSTACK_API_VERSIONS = {
     "identity": 3,
}

OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True

To fully test the domain admin functionality, the v3 policy file will need to be copied to openstack_dashboard/conf/keystone_policy.json as well.

Outside Dependencies
====================
Support obtaining a domain scoped token in django_openstack_auth
This functionality will need to be released and the minimum version of django_openstack_auth in openstack/requirements updated to that released version.

The functionality has existed in Keystone since Grizzly.

Sample v3 policy file for Keystone [2] will be used for reference and support testing.

Requirements Update Required
========================
See above requirement to release and update version of django_openstack_auth.

Doc Impact
=========
The doc impact of this change will be to the overall openstack documentation regarding domain management.

[1] https://blueprints.launchpad.net/django-openstack-auth/+spec/domain-scoped-tokens
[2] https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json