Implement type label nudger processor

Objective

Reduce maintenance for updates to type label nudge and allow for easier rollout to projects

Why is this important?

The 3 types (Bug, Feature & Maintenance) is key to our report to industry analysts. It is important for GitLab to communicate effort spent into a format that is easily understandable widely in the industry. We provide this metric to our leadership reporting and improve the accuracy with subtypes categorization.

Additionally tracking accurate work output allows the team to compare output to backlog and adjust focus accordingly.

Proposal

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. => !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
3. Expand to all is_part_of_product projects

: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.