Add quota support to Openstack Tenants

Adds support for collecting and storing openstack quota details form various openstack services.

* Adds STI to tenants to support authentication records for tenants
* Adds `cloud_resource_quotas` table and models
    * with STI to support OpenStack specific quotas
* Updates Openstack inventory collection
    * fixes the way that openstack tenants were collected
    * collects quotas based on services and tenants
        - e.g., in Tenant "ABC", the "compute" service allows for 30 vCPUs

Caveats:

* Currently, the Fog library only supports getting quota values based on Tenant.  There's no way to get quota values for specific users through Fog.  This means that Openstack Administrators can only manage quota values available to ManageIQ via the Tenant quota settings, and not the specific quota values associated with the tenant admin user.

This can either be merged as is (after the reviews), or wait until additional support for tenant authentication records is complete.  We can discuss that in the feedback for this PR.

@Fryguy, please review
No, I think that's the point of the PRs ... let's hash it out here.  Gotta make sure we're all on the same page and agree on the direction.

If something I'm doing is going to really screw up something somewhere else, better to know now.

Here's what I've found with the openstack services.  The admin user of the admin tenant can see the complete list of tenants and can see the complete list of users.  But, I believe I've also seen where the admin user of the admin tenant is not able to see all of the objects under all of the tenants.

If we could guarantee that:

1.  The admin user of the admin tenant could see all objects in all tenants, and 
2.  Openstack admins were comfortable with always providing this user's credentials for the EMS connection

then, it's possible that we could work around any other issues relating to separate tenants.

For instance, we would still collect all of the tenant information.  We'd collect the list of tenants, the quotas in different tenants, and decorate the various objects with tenant information (what Vms live in which tenants, etc...).

Then, during provisioning, we would provide the user with the ability to select the tenant where they want the newly launched VM to show up.  This would require that, not only can the admin user of the admin tenant see all objects in all tenants, but also be able to create objects in all tenants.  I'm not sure how fine grained the access control is in Openstack.  But, we could nail that down, too.

This type of implementation would allow us to gather all the required information across all tenants without having to establish connections for each tenant in order to retrieve each tenant's child objects.

This is effectively what we do today with the Openstack Inventory.  The main sticking point is whether we can rely on the users to always be able to provide the super admin credentials.

.... went off to read some openstack docs ....

According to the docs (http://docs.openstack.org/trunk/openstack-ops/content/projects_users.html), any super admin should have full permissions in all tenants (aka, projects).

I know we've seen a situation where we didn't get *all* of the data back we were expecting (i.e., rows were missing).  But, that might be some what that Fog is retrieving the data (using a publicURL endpoint instead of an adminURL endpoint, maybe).