Add feature staging guidelines

[ahmedwaleedmalik]

Due to the recent back-and-forth that we had regarding how a feature should be "marked" as alpha/beta/experimental, i'm resorting to formally documenting the feature stage guidelines to ensure that when we mark a feature alpha or beta all the required components(docs,UI,APIs, etc) also explicitly mark and document them as "alpha/beta".

IMO this document is not introducing anything new, it's just formalising what we have always been following at Kubermatic with "experimental" features.

[kubermatic-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from ahmedwaleedmalik. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[csengerszabo]

Newly introduced features in general should rather always have a switch in the admin panel which turns them fully off and on (besides the feature gate).

Therefore, if the platform admin decides to turn a feature on, it's enough to have these marks for the platform admin, as from that point, it's their responsibility to let their custumers / users use these features. Marking features throughout all the user personas of KKP could be confusing to the end users in several cases.

The possibility to turn a feature on and off by the Platform Admin of KKP should solve this issue, and the Platform Admin should always be 100% aware if a feature is in Beta.