IM/Zen support for authentication/authorization with OIDC+LDAP

CPFS Support for OIDC+LDAP ( to support CP4BA migration use cases)

Description:

The main request is about support for OIDC+LDAP in IM, but this RFE has in fact a much broader scope.
It also includes requests for:
improvements to the IM UI, to make it easier to understand what each configuration is for and how it will be used.
improvements to the documentation, to better explain which scenarios are supported, and what are the authentication/authorization flows between the configured IdPs, IM, Zen and the Cloud Pak components.

Today a lot is missing or is very difficult to find or understand. For example:
* what is the purpose the LDAP SCIM mapping, when do they come into play?
* when is a call made to the various providers to retrieve information about the user?
 when is the call skipped and the system relies on the content of the token instead?
* how are IM, Zen, and Cloud Pak components (for example, BAW) working together to manage authentication and authorization?
* what information is required for IM to act as a SCIM provider for the Cloud Pak components, and where does it get this information from (token, LDAP/SCIM, etc.)

Regarding support for OIDC+LDAP: an OIDC token doesn't always contain all the information that is currently mandatory in the IM OIDC configuration.
In particular, groups or roles are not always included.
The Cloud Pak must be able to authenticate the users with a minimal amount of information extracted from the token,
and should be able to fetch any missing information required for authorization (group membership) from LDAP or SCIM providers.

The mandatory OIDC mapping should therefore be kept to a minimum, and should only include the sub (or equivalent) and optionally another attribute that will be used for the LDAP or SCIM search (preferred_username or something equivalent, for when the sub itself cannot be used as an LDAP/SCIM attribute).
The other OIDC mappings (groups, email, display name, etc.) should only be optional, or should be requested only when authorization must also be managed via OIDC.

NOTES:
- it should be possible to work with multiple LDAP/SCIM providers.
- all the previous requirements also apply to SAML or SAML+LDAP, there is no reason to treat SAML and OIDC differently.

A typical scenario that should be supported by this enhancement is:
- An Active Directory domain containing the business users for one entity. (In our customer situation these are the system administrators)
- An additional LDAP provider (possibly of a different type, such as TDS, LDS, etc.) containing users from a different entity. (using attributes which are not the same as the AD default attributes)
- A Keycloak IdP, federating all the users from both LDAP domains and acting as an OIDC (or SAML) provider. It is not including groups in the token.(That is not the case with BIT but shouldn’t
- CP4BA, configured to authenticate users via Keycloak/OIDC (for SSO) and to authorize users based on LDAP group membership.
- The CP4BA components would be configured to use IM as a SCIM provider to retrieve user/group information.