EE: Add per-project override support for cascading settings

What does this MR do and why?

This MR introduces a per-project override mechanism for cascading instance-level settings. It adds a CascadingSettingOverride model and database table that stores override records keyed by project and optional namespace.

The CascadingProjectSettingAttribute concern's generated attribute reader is extended with a hook that checks for an override record before applying the locked-ancestor value, so a project with an override record returns its override value even when an ancestor has locked the attribute for all other projects. Two authorization tiers are enforced via CascadingSettingOverridePolicy: instance admins can grant global (namespace-scoped nil) overrides, and top-level group owners can grant namespace-scoped overrides. Cascade services (CascadeDuoSettingsService, CascadeWebBasedCommitSigningEnabledService) exclude overridden projects from batch update_all calls so a cascade run does not clobber the override.

Push rule settings (reject_unsigned_commits, commit_committer_check, reject_non_dco_commits) gain override support via an intercept in PushRule#read_setting_with_global_default. Three REST endpoints (GET|POST /projects/:id/cascading_setting_overrides, DELETE /projects/:id/cascading_setting_overrides/:override_id) provide the management interface, with full granular PAT token permission coverage and regenerated OpenAPI and permission docs.

Why was this MR needed?

Issue #587096 was filed because a customer needed to exempt one specific project from the instance-wide commit_committer_check push rule without disabling the rule for every other project on the instance. Because GitLab's cascading-setting mechanism propagates and locks values top-down with no escape hatch at the project level, there was no supported way to grant this exemption. Investigation of the closed MR !148271 (closed) confirmed the approach was previously scoped out; this MR implements that approach end-to-end, including the authorization layer, cascade-service protection, and REST API that the earlier draft lacked.

What are the relevant issue numbers?

Closes #587096

Screenshots / Recordings (if applicable)

This MR contains only backend changes (database migrations, model/concern, policy, service modifications, and API endpoints). No UI components were added or changed.

MR acceptance checklist

• Project-level overrides can be configured for cascading settings
• Override functionality works specifically for push rule settings
• Changes are backward compatible with existing configurations
• Appropriate permissions are enforced for override capabilities
• Tests added for new/changed behavior
• All tests passing
• Follows project style guide
• No breaking changes introduced

Related to #587096