Add setting for projects to access SPP repository to fetch PEP configs

What does this MR do and why?

This change adds a project setting that allows to grant repository access to SPP project for the linked projects.

This is necessary because user may not have permission to the Security Policy Project where the linked Pipeline execution policy configuration is stored. In such case, the user is not able to run pipelines in projects where the PEP is enabled.

For follow-up MRs:

• Add a cascading group setting
• Add the settings into the UI

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Before	After

Database

linked_to_security_policy_management_project?

With only project configurations:

Plan: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/31216/commands/96963

SELECT 1 AS one FROM "security_orchestration_policy_configurations" WHERE "security_orchestration_policy_configurations"."security_policy_management_project_id" = 58486266 AND "security_orchestration_policy_configurations"."project_id" = 58486314 LIMIT 1;

Time: 3.622 ms
  - planning: 0.706 ms
  - execution: 2.916 ms
    - I/O read: 2.830 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 3 (~24.00 KiB) from the buffer pool
  - reads: 3 (~24.00 KiB) from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

With project and namespace configurations:

Plan: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/31216/commands/96965

SELECT 1 AS one FROM "security_orchestration_policy_configurations" WHERE "security_orchestration_policy_configurations"."security_policy_management_project_id" = 58486266 AND ("security_orchestration_policy_configurations"."project_id" = 58486314 OR "security_orchestration_policy_configurations"."namespace_id" IN (88281517, 59720986)) LIMIT 1;

Time: 1.979 ms
  - planning: 1.133 ms
  - execution: 0.846 ms
    - I/O read: 0.714 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 5 (~40.00 KiB) from the buffer pool
  - reads: 1 (~8.00 KiB) from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

How to set up and validate locally

1. Create a group
2. In the group, create two subgroups: Dev and Compliance
3. In the Dev group, create a project Test.
4. In the Compliance group, create a project SPP.
5. Inside SPP, create two files:
   1. secrets.yml:

   include:
     - template: Jobs/Secret-Detection.latest.gitlab-ci.yml
   
   compliance-job:
     stage: .pipeline-policy-post
     script:
       - 'echo "Compliance"'

   2. .gitlab/security-policies/policy.yml:

   ---
   pipeline_execution_policy:
     - name: Secrets detection
       description: Enforce secret detection via PEP.
       enabled: true
       pipeline_config_strategy: inject_ci
       content:
         include:
           - project: <group-path>/compliance/spp
             file: secrets.yml
   

6. Go to the group Dev -> Secure -> Policies and link the Compliance -> SPP project as security policy project
7. In the project Dev -> Test, go to Pipelines, run a pipeline and ensure that jobs from PEP are added
8. Add another member into Test project with the role Maintainer.
9. Impersonate this user and run a pipeline again
10. Verify that there is "Access denied" error
11. Enable the project setting:

    Project.find(<SPP-project-id>).project_setting.update!(spp_repository_pipeline_access: true)

12. Run a pipeline again and verify that pipeline is created with PEP jobs, although the user does not have access to Compliance -> SPP -> secrets.yml

Related to #469439 (closed)