Add modeling for template many-to-many tenant

In OpenStack, an image (TemplateOpenstack) can exist in more than one project
(CloudTenantOpenstack).  These migration and model changes allow an OpenStack
template to list the tenants it can be used in, and allows a Cloud Tenant to
list the templates associated with it.

The table is named "cloud_tenants_vms" to reflect the physical tables used in
for the join.

Despite the table name referring to the generic objects, the relationship is
purposefully restricted to Openstack templates and Openstack cloud tenants in
the association defined in the models.  This keeps the notion of the
many-to-many relationship restricted to the most specific level.

The relationship methods are named:

* TemplateOpenstack#cloud_tenants
* CloudTenantOpenstack#opentack_templates

Additionally, to facilitate keeping the relationship as specific as possible,
CloudTenant is now sublassed to CloudTenantOpenstack.  Since all of the existing
cloud tenants are only openstack tenants, the migration initializes all of the
CloudTenant records to have a type of CloudTenantOpenstack.
Well, from a calling perspective you don't care that's it's openstack, you just want templates...the fact that it's openstack is not important, or rather, is a side effect of the types you'll get back.  Keeping it ducktypable make things like implementing provisioning easier.  For example, they can have a "source" object that is either EmsAmazon, EmsOpenstack, or CloudTenantOpenstack, depending on the nature of what's being provisioned, and just call `.miq_templates`.  If the method is openstack specific, the callers have to have conditional logic that's not necessary.