Update vulnerability SLO pings to include fixes not yet available

What does this MR do and why?

This MR adds the Vulnerability::Vendor PackageFix Unavailable label to the list of forbidden labels for SLO near-breach and breach notifications. We currently include Vulnerability::Vendor PackageWill Not Be Fixed in the list of forbidden labels, and these labels have similar intent. Security's vulnmapper automation correlated vulnerabilities with vendor advisory data to determine if fixes are available addressing vulnerability findings.

Per the handbook page, if a fix is not available, either Vulnerability::Vendor PackageFix Unavailable or Vulnerability::Vendor PackageWill Not Be Fixed is added as a label to tracking issues automatically to indicated that the issue is not actionable by the responsible group. When a fix is made available, the label is replaced (as it is scoped) with Vulnerability::Vendor PackageFix Available. Currently we only exclude Vulnerability::Vendor PackageWill Not Be Fixed, which is used only when a vendor has indicated they will not be releasing a fix (normally because the vulnerability does not impact their packaged version). However, we should also add Vulnerability::Vendor PackageFix Unavailable as this is applied when a fix will be available in the future, but from an SLA perspective, the SLA/SLO clock would not start until a fix is available, so the reminders are not necessary and often disruptive to development groups.

%{first_multiline_commit}

Expected impact & dry-runs

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

See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.

Action items

• If adding environment variables for reactive processors, update config/triage-web.yaml and .gitlab/ci/triage-web.yml
• (If applicable) Add documentation to the handbook pages for Triage Operations =>
• (If applicable) Identify the affected groups and how to communicate to them:
  • /cc @person_or_group =>
  • Relevant Slack channels =>
  • Engineering week-in-review