Security policy job index name pattern for custom scans

What does this MR do and why?

This makes jobs defined in custom scans use the same index name pattern as other security policy scan jobs. Custom scans can define any jobs. When the jobs get injected into the pipeline, they will get the policy index number attached to the job name. For example, "build" will become "build-0".

This is to:

• Avoid conflicts with project job names.
• Make it easy to identify the policy that injected the job

This MR doesn't fulfill all requirements #432046 (closed). The additional requirement is that, if a project job has a job named job-0 for example, the security policy should avoid a conflict and name the job job-0-0. I'll work on this in a separate MR.

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.

How to set up and validate locally

1. Create a group
2. Go to Settings -> General
3. Toggle the Permissions and group features section
4. Enable Security policy pipeline execution action
5. Create a project
6. Add a .gitlab-ci.yml file containing a variable:

   build job:
     stage: build
     script:
       - echo "Project CI"

7. Go to Secure -> Policies
8. Select New policy
9. Select Scan execution policy
10. Switch to .yaml mode and paste the following policy:

    type: scan_execution_policy
    name: Compliance
    description: ''
    enabled: true
    rules:
      - type: pipeline
        branch_type: all
    actions:
      - scan: custom
        ci_configuration: |-
          build job:
            stage: build
            script:
              - echo "Security policy CI"

11. Select Configure with a merge request and merge the MR
12. On the project page, Select Build -> Pipelines
13. Select Run pipeline
14. Observe that the pipeline contains two jobs: build job-0 and build job

Related to #432046 (closed)