make configurable in which part of the OIDC exchange custom claims should be sent

In the authorization code flow, custom claims can be sent either in the "id_token" or by querying the "userinfo".

If the client made a preference as to where the claims should be by setting the "claims parameter", the module honours this and sends accordingly.

If no preference is indicated by the client, the module currently sends custom claims always via the userinfo endpoint. As per OIDC core spec, the claims /could/ alternatively be sent directly in the id_token.

The issue at hand suggests to make configurable where a specific custom claim should be sent. The suggested place is the OIDC-to-SAML attribute mapping table, as this lists every single claim

Example, for a hypothetical custom claim "foobar":

    // The default translate table from SAML attributes to OIDC claims.
    ModuleConfig::OPTION_AUTH_SAML_TO_OIDC_TRANSLATE_TABLE => [
...
          'foobar' => [
             'attribute' => 'urn:x-randomvendor:attibute-xyz',
             'dest' => 'userinfo' # or 'id_token'
          ],

There should be a backwards-compatible default (single-string array defaults to "userinfo", to keep the current behaviour).

An open question is how to prioritise if the client did send a claim parameter, but the configured destination differs from the configured destination - which one wins?

Beginne mit der OIDC-to-SAML-Attributzuordnungstabelle und verfolge den Authorization Code Flow, der benutzerdefinierte Claims an den userinfo endpoint oder in den id_token sendet. Definiere, wie die Zuordnung einen abwärtskompatiblen Standardwert von userinfo unterstützt, und kläre anschließend, wie ein expliziter client claims parameter mit dem konfigurierten Ziel interagieren soll. Als erledigt gilt die Aufgabe, wenn jeder konfigurierte benutzerdefinierte Claim korrekt weitergeleitet wird, ohne bestehende Standardwerte zu ändern.