Add exposure scope to security policies

What does this MR do and why?

This change adds support for scoping security policies using security attributes from the exposure category.

Previously, security policies could be scoped to specific projects, groups, and compliance frameworks. Now policies can also be configured to include or exclude projects based on their exposure classification (such as "Internet Facing").

This addition is similar to the work we did in !228920 (merged), !229939 (merged), and !232179 (merged).

To avoid making this MR bigger, the policy re-sync trigger for policies using security attributes from the exposure security category will be added in !232384 (merged).

References

Related to: #596631 (closed)

How to set up and validate locally

1. Create a new group
2. Go to Secure > Security Configuration
3. Click in Exposure level
4. Click in Create attribute
5. Add a name(e.g Internet Facing) and description(e.g Internet Facing)
6. Click in Add attribute
7. Click in Save changes
8. Create a new project
9. Add a .gitlab-ci.yml file with the content:

include:
- template: Jobs/SAST.gitlab-ci.yml

10. Go to Secure > Security Configuration
11. Select Security attributes
12. Click on Edit project security attributes
13. Select the Application security attribute created in step 6(e.g Internet Facing)
14. Click in save changes
15. Go back to the group created in step 1
16. Go to Secure > Policies
17. Click on New policy
18. Select Merge request approval policy
19. Create a policy to block new vulnerabilities on Internet Facing projects
20. Get the security_attribute id

category = Security::Category.where(template_type: "exposure", namespace: Group.last)
Security::Attribute.where(security_category: category).where(name: "Internet Facing").first

21. Create a policy like

approval_policy:
  - name: Test
    description: ''
    enabled: true
    rules:
      - type: scan_finding
        branches: []
        vulnerabilities_allowed: 0
        severity_levels: []
        vulnerability_states: []
        scanners:
          - type: sast
            vulnerabilities_allowed: 0
            severity_levels:
              - critical
              - high
            vulnerability_states:
              - new_needs_triage
            vulnerability_attributes:
              false_positive: false
    policy_scope:
      exposure:
        including:
          - id: <security_attribute_id>
    actions:
      - type: require_approval
        approvals_required: 1
        role_approvers:
          - developer

22. Click on Create new project with the new policy
23. Merge the MR to add the policy
24. Go back to the project created in step 8
25. Create a MR adding the file vuln.rb with the content

class RunScript
  def run_script
    system("cat #{params[:path]}") 
  end
end

26. Verify the MR is blocked
27. Create another project
28. Add a .gitlab-ci.yml file with the content:

include:
- template: Jobs/SAST.gitlab-ci.yml

29. Create a MR with the same vuln.rb and verify the MR is not blocked.

MR acceptance checklist

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