Add EE events folder to MarkUsedFeatureFlags rubocop check

What does this MR do and why?

Currently MarkUsedFeatureFlags cop doesn't take EE events into account. For example: https://gitlab.com/gitlab-org/gitlab/-/jobs/2938445319

This MR adds ee/lib/ee/gitlab/usage_data_counters/known_events/*.yml to usage data counter events.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

1. Create a new event in ee folder, for example:

diff --git a/ee/lib/ee/gitlab/usage_data_counters/known_events/common.yml b/ee/lib/ee/gitlab/usage_data_counters/known_events/common.yml
index aa48bb0478cee648c1cc87f69b6732f768074581..26376d102042bab669b72eb4fc0ebdd748788c43 100644
--- a/ee/lib/ee/gitlab/usage_data_counters/known_events/common.yml
+++ b/ee/lib/ee/gitlab/usage_data_counters/known_events/common.yml
@@ -58,3 +58,8 @@
   category: compliance
   redis_slot: compliance
   aggregation: weekly
+- name: i_ci_secrets_management_vault_build_created
+  category: ci_secrets_management
+  redis_slot: ci_secrets_management
+  aggregation: weekly
+  feature_flag: new_super_duper_flag

2. run rm -f tmp/feature_flags/*.used
3. run Rubocop check as bundle exec rubocop --only Gitlab/MarkUsedFeatureFlags --cache false
4. Make sure there is no change related file created in the tmp folder (`ls tmp/feature_flags/ | grep new_super_
5. checkout the subj branch
6. repeat steps 2 and 3.
7. make sure the file exists now

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.