Abstract `Feature Flags` usage patterns

Description of the proposal

This builds on top of:

• Introducing memory flipper: !33054 (merged)
• This predates the !31610 (closed)
• The intent is to move closer towards: https://gitlab.com/gitlab-org/labkit-ruby/-/issues/12

This MR does introduce a Rubocop rule to disable usage of Feature.get as it exposes internals of Flipper. Instead it provides a methods as part of class Feature to control different feature flags activation mechanisms.

In more detail it does:

• Add AvoidFeatureGet rule
• Makes half of class Feature to be private
• Adds Feature.enable_percentage_of_time/disable_percentage_of_time
• Adds Feature.enable_percentage_of_actors/disable_percentage_of_actors
• Updates our development guidelines to use these methods
• Updates 99% of existing code to use stub_feature_flags or use Feature.enable/disable*
• Adds rule disable for #217490 and b8829383 as this can be addressed separately
• Part of class Feature we have all possible usage patterns of todays feature flags exposed

The impact:

• Less leaking abstractions of Flipper to codebase
• More consistent interface (I hope) better presenting different usage patterns
• With !33054 (merged) this makes our feature flags in tests behave exactly the same as they behave when running application

The development impact:

• Not really any, I hope: you just use feature flags as you were using

Check-list

• Make sure this MR enables a static analysis check rule for new usage but ignores current offenses
• Mention this proposal in the relevant Slack channels (e.g. #development, #backend, #frontend)
• If there is a choice to make between two potential styles, set up an emoji vote in the MR:
  • CHOICE_A: Agree
  • CHOICE_B: Disagree :)
  • Vote yourself for both choices so that people know these are the choices
• The MR doesn't have significant objections, and is getting a majority of 👍 vs 👎 (remember that we don't need to reach a consensus)
• (If applicable) One style is getting a majority of vote (compared to the other choice)
• (If applicable) Update the MR with the chosen style
• Create a follow-up issue to fix the current offenses as a separate iteration: ISSUE_LINK
• Follow the review process as usual
• Once approved and merged by a maintainer, mention it again:
  • In the relevant Slack channels (e.g. #development, #backend, #frontend)
  • (Optional depending on the impact of the change) In the Engineering Week in Review

/cc @gitlab-org/maintainers/rails-backend