Generic authentication implementation with support for plugable omniauth provider

Description

Gitlab in current implementation supports integration with external SSO providers with multiple limitations as:

doesn't provide an easy mechanism to integrate new providers
in case the SSO has 2FA enabled the user/app can make use of an access token as password for CLI, but can not be delegated to the IAM for authentication (central access token management outside of Gitlab)
the current implementation expects the password to be stored in the Gitlab DB that is synchronized by the LDAP provider. This is not always possible as the LDAP is just an backend for the IAM and is not exposed for Gitlab

The change can be introduced in smaller steps:

Generic implementation for the authentication with login and password to delegate to a provider specific implementation that can support one or more of the following mechanisms (more can be added in the future):
check the internal stored password
make calls to an external system (like LDAP)
check password if it is private access token
check if app/ci token is used
Rework omniauth callback controller to use a factory pattern for creation of the User based on the provider id and not have hard-coded scenarios
Generic implementation for the logout to delegate to a provider specific implementation
Implement an auto registration mechanism for external providers that implement the Gitlab omniauth enabled interface
Support for multiple configured providers (federation) of the same type. For example: if two IAM separated systems are providing standard OAuth2 SSO (one to provide company internal users and one form an external partner company)allow the possibility to configure at the same time two oauth2 providers with different provider names.