[WIP] In progress -  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.
*Much* easier to test.  With data migrations you typically have stub models, and models need to reset their column information when schema changes, making you have to jump through weird hoops.  If you split it, the stub models become static, and it's much less confusing.