Integrate with the Key module

Looks ok

This needs to be made a lot more robust.. Imagine you have a running site using this module just fine, and then decide to enable the key module.. Suddenly your keys no longer work, as the code in #2 suddenly expects that the configuration values refer to keys with the same name managed by the key module.

The way this should work is to refactor the client id and secret configuration to add a "provider" attribute that indicates the use of the key module. Naturally, the module should then be blocked if the key module is disabled.

I have created a merge request that reworks this concept, as suggested by jcnventura.
It adds a "credentials_provider" to the plugin configuration, that defaults to "config", which will just keep on storing the client_id and client_secret in the plugin configuration, as is the case currently.
If the "Key" module is installed, an optional second credentials provider gets added to the dropdown list, and users are able to optionally select a multivalue key for retrieving the appropriate credentials.

If the Key module is not installed, nothing changes. If the key module is installed, nothing changes by default, but you can opt-in to use a Key rather than providing the credentials inline.

Thanks for reviewing this MR and considering whether this could be added to the module.

Patch version of the current MR state, for Composer based patching workflows.

Updated the MR to fix a merge conflict with hook_update_x numbering.

Rebasing / fixing of merge conflict causes a new issue in test Drupal\Tests\openid_connect\Functional\Update\IssAllowedSchemaUpdate30004Test::testUpdateHook30003

Not sure how this is related, except that earlier hook also updated plugin config. Maybe it now fails because in our update hook we also update the plugin config further.
Any insights from maintainers as to how to solve this would be appreciated.

Without commenting on the failing test, I've attached a re-rolled Composer patch that works against current 3.x-dev for anyone relying on this functionality (like me!)

Rerolled against latest update to fix conflict with prompt update hook.

Rebased MR. All tests pass now.

Just tested this out on one of my sites and it works great - I would love to see this merged into the next release!

Changed because of MR comment. If it is not relevant please change back

Addressed my feedback. Definitely could not submit the form after selecting a key because of the missing values.

I re-worked the key integration to only require the client_secret. Client ID's are public.

I also added tests to
- Validate the Key integration
- Validate that the downstream openid_connect_windows_aad didn't break (they already have Key integration).
- Reworked the update hook to _not_ rely on plugins, but just edited the configuration directly.

- [ ] We need to followup with the windows_aad to have their schema updated.

Merged latest changes and resolved conflicts.

Failed asserting that Array &0 [
    'openid_connect.client.acm_idm:settings.credentials_provider' => 'missing schema',
    'openid_connect.client.acm_idm:settings.credentials_key' => 'missing schema',
] is true.

This is a bug I'm not sure how to handle. Since it doesn't extend the base schema it doesn't get the updated schema definition. Is the expectation that sub modules should update their schema definition to include this?