feat(openid-connect): add consumer selector for consumer-group realm routing

[PiyushMishra318]

This PR adds an optional consumer_selector capability to the openid-connect plugin, allowing a single route to select a Consumer (and Consumer Group) from a JWT claim (for example, iss) before OIDC validation.

With this flow, APISIX can apply realm-specific openid-connect configurations from Consumer Groups deterministically on one route, without requiring key-auth pre-resolution.

Changes included:

• Added consumer_selector schema fields in openid-connect:
  • enabled
  • claim (default iss)
  • map (claim value -> consumer name)
  • strict
• Added selector logic to:
  • extract bearer token
  • decode JWT payload claim
  • resolve/attach mapped consumer
  • load selected Consumer Group’s openid-connect config
  • continue normal OIDC validation/header-setting flow (including X-Userinfo)
• Added consumer.get_consumer(name) helper and safe local-cache cloning in consumer.lua
• Added tests for selector schema validation in t/plugin/openid-connect2.t
• Updated plugin documentation in docs/en/latest/plugins/openid-connect.md

Which issue(s) this PR fixes:

Fixes #13037

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)

[PiyushMishra318]

Thanks in advance for reviewing this PR.

I’m happy to iterate on the implementation based on maintainer feedback, including behavior changes, API/schema adjustments, additional tests, or splitting this into smaller PRs if that is preferred.

[Baoyuantop]

A better approach is to directly support multiple Issuer configurations (valid_issuers + multiple discovery) within the openid-connect plugin, instead of distributing routes via "unsigned JWT Claims". Consider supporting multiple Issuer configurations directly within the openid-connect plugin (each issuer corresponds to a set of discovery/client_id/client_secret), which is a more secure and concise solution, eliminating the need for routing before signature verification.