Expand merge request type label realtime reminders to more projects

Objective

Migrate merge request type label automation to event driven automation to simplify expansion to other projects and future iterations of the nudge message.

Background

In FY23Q1, Engineering Productivity added tooling to infer and guide merge request authors to apply a ~type::* label which led to a reduction in Undefined Merged MRs from 30% to 15%.

One effective reminder was a Danger rule rolled out to largest offending projects. After rolling this out, we found that future changes would require updates in each project and started discussing how this rule can be iterated on more effectively across projects leading to gitlab-org/quality/engineering-productivity/team#21.

Plan

1. Create a type label discussion for non-~"Community contribution" MRs opened without a type for the top 20 offending undefined projects with the below message requesting the MR be classified label. => gitlab-org/quality/triage-ops!1374 (merged)
2. Expand to additional projects based on undefined ratio (what proportion of merged MRs do not have a type) for projects over 20 MRs in the last 90 days => gitlab-org/quality/triage-ops#1004 (closed)
3. Expand to all is_part_of_product projects => gitlab-org/quality/triage-ops#1005 (closed)

:wave: @#{event.event_actor_username} - please add ~"type::bug", ~"type::feature", ~"type::maintenance", or a [subtype](https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification) label to this merge request. 

        - ~"type::bug": Defects in shipped code and fixes for those defects. This includes all the bug types (availability, performance, security vulnerability, mobile, etc.) 
        - ~"type::feature": Effort to deliver new features, feature changes & improvements. This includes all changes as part of new product requirements like application limits.
        - ~"type::maintenance"`: Up-keeping efforts & catch-up corrective improvements that are not Features nor Bugs. This includes restructuring for long-term maintainability, stability, reducing technical debt, improving the contributor experience, or upgrading dependencies.

        See [the handbook](https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification) for more guidance on classifying.