feat: add per-client and connector-level(LDAP) allowedGroups

[DoMaLo]

Overview

This PR adds per-client and connector-level group restrictions so that only users in configured groups can complete SSO for a given OAuth2 client or connector.

• Per-client allowedGroups: Optional list of groups on each OAuth2 client (storage + static config). Only users in at least one of these groups can complete login for that client. One connector can serve many clients; each client can have its own list.
• LDAP connector allowedGroups: Same pattern as existing OIDC/SAML connectors: optional allowedGroups in LDAP connector config; only users in those groups can log in through that connector.
• Scopes and tokens: When a client has allowedGroups, Dex adds the groups scope for the connector call (so groups are available for the check) but does not add it to the auth request scopes, so the issued token does not contain a groups claim unless the client requested the groups scope.
• Errors: Users not in any required group receive HTTP 403 with a clear message instead of 500.

All storage backends (memory, Kubernetes, SQL, ent), gRPC API (CreateClient/GetClient/ListClients), and static config are updated. Backward compatible: empty or missing allowedGroups means no restriction.

What this PR does / why we need it

• Addresses use cases from issue #1562 (Mandate Group Search Condition in Dex LDAP Connector): LDAP connector allowedGroups allows mandating that only users in certain groups can log in; if group search returns no groups or the user is not in the allowed list, login fails with 403.
• Consistency across connectors: OIDC and SAML already support connector-level allowedGroups; this PR adds the same to LDAP and introduces a per-client restriction so that different applications (clients) can require different groups without separate connectors.
• Kubernetes and multi-tenant setups: When Dex is used with multiple OAuth2 clients (e.g. different apps or namespaces), per-client allowedGroups lets each client restrict access to its intended set of groups. Works with Kubernetes storage (OAuth2Client CRD) and static config.

Special notes for your reviewer

• Tests: Unit and integration tests added for per-client allowedGroups (connector callback and password login), client with no allowedGroups, token without groups when scope not requested, API CreateClient/GetClient roundtrip, storage conformance (ClientCRUD with AllowedGroups), and pkg/groups Filter. LDAP TestAllowedGroups exists (skipped when DEX_LDAP_HOST is not set).
• DCO: All commits are signed off (Developer Certificate of Origin).
• Breaking changes: None. Existing configs and CRDs continue to work; new fields are optional.

[nabokihms]

Hello, and thank you for the PR.

1. As for now, we do not accept per-client group filters or anything per-client. There is a PR hanging since 2019 Add allowedGroups option for clients config #1583
2. For ldap, we already have a filter for groups. Do we need to add a second filter option? Probably not. Maybe instead we can control the filter behavior to fail if there is an empty group result after the filtering.