Draft: Introduce troubleshooting section for scan result policies

What does this MR do and why?

This MR updates the documentation on scan result policies to introduce a Troubleshooting section. The goal of this MR is to deflect tickets and make it easier for folks to resolve trouble they may encounter with a trip to the docs.

Here are all of the notes we took from this:

Through this pairing session, we discussed updating the docs to:

• Introduce a Troubleshooting section to the Scan result policies docs that describes:
  • Please wait up to 10 minutes for policy to take effect.
  • The rule will appear but be optional if the criteria are not met; it will appear and be required if the criteria are met.
  • It is possible to configure a rule that can not be satisfied: here's what will happen and the issue with more info. (✨ ambiguity ✨ )
  • It is possible to do things in .yaml mode that can not be brought back to Rule mode. This is clear but add it to troubleshooting.
• Update the docs to clarify this section is about the target branch of the MR:

| branches | array of string | * or the branch’s name | The branch the given policy applies to (supports wildcard). |

• Add Security::OrchestrationPolicyConfiguration.with_outdated_configuration.where(project_id: 278964) to the GitLab Rails Console Cheat Sheet -- or this docs page.
• 🆕 If I want to point someone to the docs to tell them the answer to "How do I create a Scan Result Policy?", I send them to:
  • Policy editor
  • The docs on Scan result policies don't make it clear how to actually create one.
• Make it clearer what the requirements are: scan in the MR is required. near.

It probably makes sense to move some of these into their own issue or MR. We'll iterate on that. 🐾

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.