Add initial version of detailed policy bot comment

What does this MR do and why?

This MR adds an initial version of detailed policy bot comment to surface policy violations to the user. It depends on Add policy violation details, extend finders (!146933 - merged) and currently supports scan_finding and any_merge_request violations.

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

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After	Optional approvals

CleanShot_2024-03-08_at_17.28.16

How to set up and validate locally

1. In rails console enable the feature flag

   Feature.enable(:save_policy_violation_data)

2. Create a project
3. Add CI configuration:

   include:
     - template: Jobs/Secret-Detection.gitlab-ci.yml
   
   build-job:
     script:
       - echo "Compiling the code..."
       - echo "Compile complete."

4. Go to Secure -> Policies and create a new policy:

   type: approval_policy
   name: Test
   description: ''
   enabled: true
   rules:
     - type: scan_finding
       scanners: []
       vulnerabilities_allowed: 0
       severity_levels: []
       vulnerability_states:
         - new_needs_triage
         - new_dismissed
         - detected
         - confirmed
         - dismissed
         - resolved
       branch_type: protected
     - type: any_merge_request
       branch_type: protected
       commits: unsigned
   actions:
     - type: require_approval
       approvals_required: 1
       role_approvers:
         - developer

5. Create MR adding a new leaked secret. Example:

   diff --git a/.env b/.env
   new file mode 100644
   index 0000000000000000000000000000000000000000..ee4bf74ac3b632173dafc09e74ecd68c298bdfa1
   --- /dev/null
   +++ b/.env
   @@ -0,0 +1 @@
   +AWS_TOKEN=AKIAZYONPI3G4JNCCWGQ
   \ No newline at end of file

6. After the pipeline completes, verify that jobs pass, artifacts are present and approvals are required
7. Verify that a bot comment is created and it lists the detected vulnerability as blocking
8. Verify that the bot comment also includes an unsigned commit listed as a reason for MR being blocked (if the commit is unsigned)
9. Merge the secret so that it becomes a previously-existing vulnerability. The vulnerability should show up in Secure -> Vulnerability report
10. Create a new MR, adding a new leaked secret. Example:

    diff --git a/.env b/.env
    index ee4bf74ac3b632173dafc09e74ecd68c298bdfa1..d791cd2180779bf094bd017e07b12c1fad506c2c 100644
    --- a/.env
    +++ b/.env
    @@ -1 +1,2 @@
    -AWS_TOKEN=AKIAZYONPI3G4JNCCWGQ
    \ No newline at end of file
    +AWS_TOKEN=AKIAZYONPI3G4JNCCWGQ
    +AWS_TOKEN2=AKIAZYONPI3G4JNCCWGZ
    \ No newline at end of file

11. After the pipeline completes, verify that the comment is updated and includes the new and previous vulnerabilities:

Related to #433403 (closed)