Require weight for "Accepting Merge Requests" label

Background/facts

• GitLab currently has 41,354 open issues. Of those, 18,976 (46%) have the "Accepting merge requests" label.
• GitLab says: "issues that are specifically suitable for community contributions are listed with the ~"Accepting merge requests" label".
• GitLab automatically adds the ~"Accepting merge requests" label to issues that are considered "ready for work".
• GitLab Product Development Flow says engineers will "apply weights" to issues before moving them to one of the ready-for-work states like workflowscheduling or workflowready for development.
• Currently GitLab has 16,087 open issues labeled ~"Accepting merge requests" with weight=None. (Thanks @godfat-gitlab)

Problem to solve

Far too many issues (roughly half of all open issues) are labeled as ~"Accepting merge requests". As a result, the label has little practical meaning or value. It seems this label has been automatically applied in most cases, which suggests the automation criteria are too relaxed.

What this MR does

This modifies the hygiene policy for the ~"Accepting merge requests" label to make the criteria more strict, by requiring that a weight has been assigned. The intent is to stop encouraging community contyributions for issues that have not been sufficiently reviewed/refined/vetted for execution by Engineering.

This is a complement to the existing rule to remove the ~"Accepting merge requests" label when an inappropriate workflow label is applied, because issues with a workflow label that indicating "ready for execution" should also have a weight. (According to the GitLab Product Development Flow, it's after the workflowplanning breakdown label is applied that a weight becomes expected: "At this point, Engineering Managers will assign an engineer to further break down and apply weights to that work.")

Technical note: A weight specification of Any "returns issues with a weight assigned." https://docs.gitlab.com/ee/api/issues.html#list-issues

Action items

• (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 =>
  • Week-in-review