Add a "remove a metric" flow to the internal events generator

Motivation

When metrics become obsolete, there is a process for removing metrics. However, engineers often seem to miss the docs or don't think to look. It could be easier for engineers to find & figure out that process.

Proposal

Add a new flow to the internal events generator that essentially steps engineers through metric removal.

‣ 1. New Event -- track when a specific scenario occurs on gitlab instances
     ex) a user applies a label to an issue
  2. New Metric -- track the count of existing events over time
     ex) count unique users who assign labels to issues per month
  3. View Usage -- look at code and testing examples for existing events & metrics
  4. Remove Metric -- deprecate an existing metric
  5. ...am I in the right place?

 Step 1 / 4 : Remove Metric > Metrics > URL > Save files > Notify stakeholders
|===========================>----------------------------------------------------------------------|

For robust metric search, use the Metrics Dictionary: https://metrics.gitlab.com

Select one: Which metrics should be removed? (Press ↑/↓/←/→ arrow to move, Enter to select and letters to filter)
  ⬢ redis_hll_counters.code_review.i_code_review_post_merge_click_cherry_pick_monthly
  ⬡ redis_hll_counters.code_review.i_code_review_post_merge_submit_revert_modal_monthly
  ⬡ redis_hll_counters.code_review.i_code_review_post_merge_submit_cherry_pick_modal_monthly
  ⬡ redis_hll_counters.ci_templates.p_ci_templates_security_dast_on_demand_api_scan_monthly
‣ ⬢ redis_hll_counters.ci_templates.p_ci_templates_implicit_security_dast_api_latest_monthly
  ⬡ redis_hll_counters.analytics.p_analytics_ci_cd_pipelines_monthly
  ...

 Step 2 / 4 : Remove Metric > Metrics > URL > Save files > Notify stakeholders
|===========================>----------------------------------------------------------------------|

Input text: Which MR URL will remove these metrics? (enter to skip) 

 Step 3 / 4 : Remove Metric > Metrics > URL > Save files > Notify stakeholders
|===========================>----------------------------------------------------------------------|

Preparing to metric update definitions with these attributes:

---
status: removed
removed_by_url: <user-input url> || "TODO"
milestone_removed: <current milestone>

Update files? (Y/n) 

 Step 4 / 4 : Remove Metric > Metrics > URL > Save files > Notify stakeholders
|===========================>----------------------------------------------------------------------|

Metric removals have the potential to break some dashboards or reporting. To notify the relevant 
stakeholders, please post this comment in the issue or MR corresponding to the metric removal: 

----
FYI - @<PMs> @<EMs> @csops-team @gitlab-data/analytics-engineers @gitlab-data/product-analysts 

The following metric(s) are being removed from service ping in <milestone>:
- `redis_hll_counters.code_review.i_code_review_post_merge_click_cherry_pick_monthly` ~"group::code review"  
     (contributes to performance indicators: smau, gmau, paid_gmau, customer_health_score performance indicators)
- `redis_hll_counters.ci_templates.p_ci_templates_implicit_security_dast_api_latest_monthly` ~"group::ci platform" 
     (contributes to performance indicators: customer_health_score)
---

When generating the comment text:

• look up the EMs/PMs for the groups of each metric (we're already have logic to pull stages.yml anyway)
  • if any metrics' groups are not found in stages.yml, post a warning like WARNING: Could not find PM/EM for <missing group>! Please ensure the team who owns these metrics is aware of the removal before merging any code changes. If the group name has changed, try the scripts/internal_events/product_group_renamer.rb script to update all definitions with the correct name. below the comment text
• conditionally include the performance indicator details/stakeholders
• insert the current milestone in the comment