Add Section, Stage, Group label reactive processor

What does this MR do and why?

Add a reactive processor to ensure Section, Stage and Group labels maintain synchronicity.

Group will always take priority over Stage and Section labels. This will allow for the least amount of changes. I.e., when a Group label is added/updated, Stage and Section labels are updated.

• When no Group Stage or Section labels exist: Do nothing
• When only a Section label is present: Do nothing
• When only a Group label is present: Infer Stage and Section label based on the Group
• When only a Stage label is present: Infer Section label based on the Stage
• When only Stage and Group labels are present
  • If the Stage and Group labels match: Only infer the Section label
  • If the Stage and Group labels mismatch: Change the Stage and Section labels based on the Group
  • When only Section and Group labels are present
    • If the Section and Group labels match: Only infer the Stage label
    • If the Section and Group labels mismatch: Change the Section and Stage labels based on the Group
  • When all Section, Stage and Group labels are present
    • If the Section does not match the Group: Change the Section label based on the Group
    • If the Stage does not match the Group: Change the Stage label based on the Group

Examples

Good:

• "section::dev" "devops::create" "group::source code"
• "section::dev" "devops::plan" "group::editor"

Bad

• "section::ops" "devops::create" "group::source code" #=> Problem: Incorrect Section; Action: change section::ops to section::dev
• "devops::create" "group::source code" #=> Problem: No Section; Action: add section::dev
• "section::ops" #=> Problem: Missing Stage and Group labels; Action: Leave a note for adding Stage and Group labels
• "section::dev" "devops::create" #=> Problem: Missing Group label; Action: Do nothing.
• "devops::plan" "group::editor" => Problem: No Section, Incorrect Stage; Action: add section::dev, change devops::plan to devops::create

Closes #1085 (closed)

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-with-a-dry-run on how to perform dry-runs.

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 =>
  • Engineering week-in-review