[#230] Restore the identity provider catalogue and fix the social provider docs

[vharseko]

Fixes #230

Depends on #226. This branch carries #226's commit ([#225] Bind identity provider configs through the DS bind methods) until #226 is merged; review only the [#230] commit here. With the
catalogue restored, IdentityProviderService activates on a stock install, and without #226 its
start-up logs SEVERE ... Field identityProviders ... has unsupported type java.util.Map (#225),
which fails the start-up check of every build-maven job. If #226 is squash-merged, this branch will
be rebased onto master to drop its copy of the commit.

The problem

The Integrator's Guide (chap-auth.adoc, appendix-auth-modules.adoc) says social identity
providers are configured in conf/identityProviders.json. They are not:

• a configured provider is a factory configuration of its own, conf/identityProvider-<name>.json
  (PID org.forgerock.openidm.identityProvider, IdentityProviderConfig.java:42-52); the Admin UI
  writes it (SocialConfigView.js:463, :475) and SOCIAL_PROVIDERS builds its modules from it
  (AuthenticationService.java:413-417);
• conf/identityProviders.json configures the identity provider service itself; its providers
  list is the catalogue returned by availableProviders (IdentityProviderService.java:183-186,
  :277), which the Admin UI offers as templates with enabled: false (SocialConfigView.js:82-85);
• client_secret is encrypted only under org.forgerock.openidm.identityProvider
  (openidm-identity-provider/.../ConfigMeta.java:44-47), so a secret put where the guide says
  stays in plain text.

On top of that the distribution ships no identityProviders.json at all: it was removed in
95c573c (OPENIDM-6689). IdentityProviderService is ConfigurationPolicy.REQUIRE, so on a stock
install it never starts, SocialDelegate.availableProviders() turns the 404 into
{providers: []}, and Configure > Social ID Providers has nothing to offer.

The change

1. conf/identityProviders.json is back, with the three providers the Admin UI has forms for
   (google, facebook, linkedIn; the names are what setDisplayIcons and the
   social/_<name>.html partials key on). The 2016 content is updated where the providers moved on:
   • google — token_endpoint and userinfo_endpoint from
     accounts.google.com/.well-known/openid-configuration; locale mapping dropped, it is no longer
     in claims_supported;
   • facebook — unversioned Graph endpoints (they follow the version pinned in the app's dashboard,
     so they do not expire the way v2.3 did); scopes public_profile, email; the discontinued
     locale field is no longer requested; the button uses fa fa-facebook, since
     images/fb-logo.png never existed in this repository;
   • linkedIn — the v1 API and r_basicprofile are gone; it now uses /v2/userinfo with
     openid profile email and authenticationId: sub. It stays OAUTH rather than
     OPENID_CONNECT: LinkedIn's id_token iss (https://www.linkedin.com) differs from the
     issuer in its discovery document (https://www.linkedin.com/oauth).
2. Docs — both sections now say a provider lives in conf/identityProvider-<name>.json (name
   taken from the file name, written by the Admin UI, client_secret stored encrypted), give a sample
   identityProvider-google.json, say that each generated module carries its provider's enabled
   flag, and describe identityProviders.json as the catalogue that must stay in place.

Default login is unchanged: authentication.json has no SOCIAL_PROVIDERS entry, and the
identityProviders route is readable by openidm-authorized only (access.js:52-56). The catalogue
holds no credentials.

Verification

On an openidm-zip-7.1.1-SNAPSHOT distribution (JDK 17) with this conf/identityProviders.json:

• IdentityProviderService activates; POST /openidm/identityProviders?_action=availableProviders
  returns google, facebook and linkedIn with the new endpoints and scopes;
• PUT /openidm/config/identityProvider/google stores client_secret as $crypto, also in the
  written conf/identityProvider-google.json;
• a client_secret put into config/identityProviders is stored in plain text, as the docs now say;
• GET /openidm/identityProviders still answers {"providers":[]} with the SEVERE ... Field identityProviders ... has unsupported type java.util.Map line — that is Configured identity providers are never bound, so /identityProviders is always empty #225, fixed by [#225] Bind identity provider configs through the DS bind methods #226, whose
  commit this branch now carries (see above); this manual check was done before that rebase.

Not verified: a real login with any of the three providers (needs registered OAuth applications,
and #225 blocks it anyway), and whether LinkedIn echoes the nonce in its id_token, which
OAuthHttpClient.getProfile checks when an id_token is present (OAuthHttpClient.java:161). The
AsciiDoc was not rendered; the new blocks follow the surrounding + / [source, json] markup and the
social-providers-module anchor exists.