Replace per-vendor OIDC providers (Keycloak, ForgeRock, ...) with a generic OIDC provider type

Start with AbstractOIDCOAuth2Provider and OAuth2AuthManagerImpl.getUserOAuth2AuthenticationProvider, then trace the oauth_provider schema, registration/update parameters, OauthProviderResponse, and Login.vue. Done means arbitrary OIDC registrations use one generic provider and dynamic login buttons, while existing Google, GitHub, and Keycloak registrations continue using their legacy beans.

Problem

CloudStack's OAuth2 plugin currently ships one hardcoded Java class and one hardcoded UI block per OIDC vendor (KeycloakOAuth2Provider, ForgeRockOAuth2Provider). Neither class has any vendor-specific logic. Both just implement the standard OIDC authorization-code flow: hit an authorize URL, exchange the code at a token URL, parse the returned id_token JWT, read the email claim. Any OIDC-compliant IdP (Okta, Auth0, Azure AD, etc.) would work against this same code unchanged.

This was called out directly in #13499, which extracted the duplicated Keycloak logic into AbstractOIDCOAuth2Provider so ForgeRock could reuse it as a thin subclass. From that PR's own description:

Perhaps in the future this should be handled as an unbound provider (just a generic OIDC provider, pluggable with any OIDC-compliant server), but for now, this'll do.

As it stands, every new OIDC IdP someone wants means a new Java class plus a new hardcoded block in Login.vue, forever, for zero actual behavior difference. It also has a real limit today: since provider is both the display name and the routing key, and dispatch is a fixed name-to-bean map, a domain can only ever register one keycloak and one forgerock. It can't run two different OIDC IdPs under arbitrary names.

Proposal

Make OIDC a generic provider type instead of one class per vendor.

• Add a type field distinct from provider (oauth_provider table + registerOauthProvider/updateOauthProvider params + OauthProviderResponse). provider stays a free-text, admin-chosen label (forgerock, okta, hr-corp-idp); type says which code runs it (e.g. oidc).
• One concrete generic OIDC bean instead of one subclass per vendor.
• Decouple provider identity from getName(). Right now it's a fixed, parameterless string baked into each bean and used for both dispatch and the bean's own DB lookups. For a shared bean serving many registrations, the provider name needs to be a parameter threaded through verifyUser/verifySecretCodeAndFetchEmail, not a compile-time constant.
• Dispatch fallback in OAuth2AuthManagerImpl.getUserOAuth2AuthenticationProvider: if no fixed bean matches a name, look up the DB row; if type=oidc, hand off to the generic bean instead of throwing.
• Move the authorizeUrl/tokenUrl-required check off the hardcoded name list (equalsAny(provider, "keycloak", "forgerock")) onto type == oidc, so it applies to any future name automatically.
• Login.vue: render OAuth buttons from the registered provider list instead of one hardcoded block per vendor. Needs a display name/icon per row (admin-supplied, or a generic OIDC icon as fallback).
• Keep google/github/keycloak legacy beans working unchanged. No forced migration, existing rows keep dispatching to their own classes. Only new arbitrary-name registrations go through the generic path.

Non-goals

• No change to Google/GitHub, they aren't OIDC and keep their own dedicated implementations.
• No forced migration of existing keycloak registrations.

Related

• #13499 (adds ForgeRock, extracts the shared AbstractOIDCOAuth2Provider base this proposal builds on)