Label automation enforcement for ~availability issues in product facing projects

Per the new ~availability Priorization and Severity scheme https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/39270 we should do a few triage-ops automation to help enforce and raise awareness. 

### Triage report 

- [x] Add a new section above ~bug to list issues that are labelled with ~availability - https://gitlab.com/gitlab-org/quality/triage-ops/issues/406

### Triage Automation

- [x] Label issues that have ~availability with ~bug. ~availability is another category of bugs. - https://gitlab.com/gitlab-org/quality/triage-ops/issues/407
  - See my reasoning here:
  - > As I stated before in https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/39270#note_280407345, ~availability issues are a category of bugs, we don't have a good hygiene on label yet (which we will fix with automation). This iteration aims to have better clarity and specifics on how to deal with bugs/defects that immediately impacts GitLab.com ~availability. The overall ~bug pie is huge, this sets out to make a subset of that better with clearer and specific actionable steps.
- [x] Enforce [prioritization band](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/39270#prioritization-band) with Triage Serverless. - https://gitlab.com/gitlab-org/quality/triage-serverless/issues/22
  - When an issue with ~availability has a Severity label, automatically add the minimally allowed Priority label.
    - ~availability ~S1 => ~P1 
    - ~availability ~S2 => ~P1 
    - ~availability ~S3 => ~P2
    - ~availability ~S4 => ~P3 
  - Enforce prioritization, we do not allow the following labels
    - ~availability ~S1 cannot have ~P2 ~P3 ~P4 it can only have ~P1
    - ~availability ~S2 cannot have ~P2 ~P3 ~P4 it can only have ~P1
    - ~availability ~S3 cannot have ~P3 ~P4 it can only have ~P2 or ~P1 (extra credit)
    - ~availability ~S4 cannot have ~P4 it can only have ~P3 or ~P2 / ~P1 (extra credit)
- [x] Draft a plan for an escalation chain when ~S1, ~S2, and ~S3 have exceeded the time to resolve. - https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/426
- [x] Add dashboards to visualize - https://gitlab.com/gitlab-org/gitlab-insights/issues/161

---- 

| Severity | Availability Impact | Reproducibility | Time to resolve | Deployment target | Minimum priority |
| -------- | ------- | -------------- | --------------- | ----------------- | ----------------- |
| ~S1 | Roadblock on GitLab.com and blocking customer's business goals and day-to-day workflow | Consistently reproducible | Within 48 hrs | Hotfix to GitLab.com | ~P1 |
| ~S2 | Significant impact on GitLab.com and customer's day-to-day workflow. Customers have an acceptable workaround in place. | Consistently reproducible | Within 5 business days | Next deployment window after resolution | ~P1 |
| ~S3 | Broad impact on GitLab.com and minor inconvenience to customer's day-to-day workflow. No workaround needed.  | Inconsistently reproducible | Within 30 days | Next release after resolution | ~P2 |
| ~S4 | Minimal impact on GitLab.com, no known customers affected | Inconsistently reproducible | Within 60 days  | Next release after resolution | ~P3 |

Merge request https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/39270/diffs

## Prioritization band

To call out specifics on what priorities can be set on an ~availability issue, please refer to the table below.

As we implement these labels, we can have triage automation enforce these priorities based on the labels set forth.

| Issue  | Allowed Priorities |
| ------ | ------ |
| ~availability ~S1  | ~P1 only |
| ~availability ~S2  | ~P1 only |
| ~availability ~S3  | ~P2 as baseline, ~P1 allowed |
| ~availability ~S4  | ~P3 as baseline, ~P2 ~P1 allowed |

Story points: 8.0