Draft: Update ask-severity-for-bug-ux-issues.yml to occur for all bugs

What does this MR do and why?

Broadens the rule that adds a reminder to issues to add a severity. Currently the rule only runs against bugux issues. The rule seems to work looking at the stats:

• 24 out of 376 bugux typebug's do not have a severity which is about 6.3%
• 547 out of 4,428 non- bugux typebug's do not have a severity which is about 12.3%

Expected impact & dry-runs

Since we are expanding it from bugux to typebug, I checked that every bugux also has the typebug label ✅

Some additional stats:

There are currently 571 typebug's without a severity

Of these bugs the breakdown is:

• bugavailability 3
• bugvulnerability 0
• bugmobile 0
• bugfunctional 163
• bugperformance 43
• bugtransient 8
• bugux 24
• no bug:: label 330

Of the 571, the groups with the most:

• 116 groupproject management
• 83 groupsource code
• 68 do not belong to a group
• 57 groupcode review
• 45 groupimport and integrate
• 21 groupglobal search
• 12 groupthreat insights

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