Draft: Add generator concept for feature flag

What does this MR do?

I wanted to use the bin/feature-flag command from within a rails generator, but there's no really great way to do that other than to shell out for it using %x or system. This felt a bit odd to me, and got me thinking about my thoughts in using bin commands in general, and the challenges we face in documenting them. Bear with me here...

Generally speaking, as programmers, we see value in self documenting code, apis, tooling, etc. as best as we can. As well as using the tools that everyone else is using -- because it's more easily understood, or self discoverable when we do this. There's also value in not waiting for Rails to load the whole application when that's not required, obviously.

So I spiked on creating the bin/feature-flag as a generator. This could've used Thor directly, but I wanted to get this into the output of rails g as part of the self documenting objective.

Anyway, I also left the bin/feature-flag command, as doing a minimal load and running it that way is way faster -- since we're really only loading rails/generators, and a couple aspects from within the application, it's still really quick to get into the questions when running it via bin/feature-flag, but we also have the benefit of being able to see it as an option, run it via rails g gitlab:feature_flag with consistent arguments, as well as invoke it from other generators if we want to (which I do).

I built out the same functionality and provided some underlying tooling that might be useful for other things, like bin/changelog, and potentially bin/setup, bin/update.

I'm ok if we don't go this route, but I think there's value in discussing it. If it's worth doing, I'll add tests for the generator, and InteractiveBase that provides an initial offering of tools to asking questions and validate responses.

Screenshots (strongly suggested)

Here are some screen shots of examples:

Visible in rails generator output:

The help output between rails g gitlab:feature_flag and bin/feature-flag are largely identical:

It generates the following output (orders as defined in Feature::Shared::PARAMS, which could probably be removed now?)

name: testing
introduced_by_url: 
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue%5Btitle%5D=%5BFeature+flag%5D+Rollout+of+%60testing%60&issuable_template=Feature+Flag+Roll+Out
milestone: 13.6
type: ops
group: group::testing
default_enabled: false

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing