[WIP] Multiple endpoints per provider feature

Below is an overview that I hope will help you understand the code changes that make up this new feature.  Please focus on overall design, keep it high level. Once it is working I will sweep through and make improvements.

General overview:

We now have a class called EMS_Connection. Which kind of “sits between” the ExtManagementSytem and the Authentication classes.
This PR excludes ALL changes to the UI, but I envision we will have a UI frame for each EMS_Connection encompassing at least: 
IP
port
hostname
provider_component eg “refresh” or “events”
existing User Credentials box

Each ExtManagementSystem will have one or more EMS_Connection(s) with the ems_id as the foreign key.
The EMS_Connection will have one or more Authentications with the ems_connection id as the foreign key.

The EMS_Connection includes the AuthenticationMixin making it easy for it to take care of the many methods we already have in place for saving and checking credentials.

A couple of things:

1) The EMS still takes care of the validate_credentials and connect methods but now depends on the credentials being passed into each method in the options hash as opposed to being directly accessible from the EMS itself. (remember the validate_credentials only has access to variables stored in memory, not the database.)

2) Workers
 - In order for the workers to start up we check if the EMS has valid credentials configured (per_ems_worker_mixin)
 After the workers have been initialized (ems_refresh_core_worker and ems_refresher_worker) we check the credentials of the EMS again, like this:

@ems.authentication_check

The new approach is to get a handle on the EMS_Connection as per the example below:
@ems.ems_connections.find_by_provider_component("refresh").authentication_check

Once I have everything working I will see if I can improve on this without passing in the string, maybe create a new method in the ext_management_system class which uses the class name instead, not sure.
I follow this approach in other places too eg the refresher parsers.
Lemme turn this around a little by applying a little future proofing.

Think about pluggable providers.  When we get to that point, the only things that really need the connections are the the provider plugins (or should be, if we do it right).  This means that the openstack plugin should be able to ask ManageIQ, "can I has the 'refresher' connection?"  Then, the provider plugin (knowing the specifics about openstack) could drill that connection down to :nova or :glance.

Just an idea, but I want to see how far we can push that notion of removing the provider-specific knowledge from the main application.