Add current milestone to all merged MRs missing a milestone

What does this MR do and why?

Add current milestone to all merged MRs missing a milestone

This rule was previously only targetting community contributions. I can't see any reason this wouldn't also apply to a normal MR where we didn't add the milestone.

This is a first step towards removing the warning from our MRs missing a milestone.

The main motivation I had for this is that the the gitlab-housekeeper MRs keep getting danger warnings about missing a milestone.

I considered adding it to that gem but it seemed like even normal developers could benefit from automatically having the milestone applied.

We also discused in slack (internal) whether we should just assign the milestone on MR creation but it seemed like that might conflict with our "missed deliverable" rules in https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/9c2e66fc48e3ab0cb3b5460fa068b00de11a654d/policies/stages/hygiene/missed-resources.yml#L37 because then people may get unnecessary missed deliverable labels for MRs that they never intended to be merged in a specific milestone.

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