Update feature privilege names to reflect new terminology

[ymao1]

As part of #90375, the feature privilege name for Stack Alerts and Alerts Examples should be updated to reflect the new terminology in the UI and any docs that might reference these privileges.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[mikecote]

++ using the new terminology, I'm guessing it would become Stack Rules but more likely, they should be Stack rule types? @arisonl @gmmorris

[ymao1]

What about Example Rule Types and Stack Rule Types

[gmmorris]

++ using the new terminology, I'm guessing it would become Stack Rules but more likely, they should be Stack rule types? @arisonl @gmmorris

I don't know 😬
Do we have some guidance on when it should be rules and when rule types? Have we spoken to @gchaps ?

[arisonl]

Here are a couple of thoughts:

• Accuracy: It is clearly a type.
• Simplicity (UX): Accuracy and UX friendliness may not always go hand-in-hand. For example: ref the privileges screenshot above: The Kibana RBAC privileges model generally secures saved object types, so in this context one could argue that "type" is redundant and "Stack Rules" is simpler and hence better. Furthermore, when you secure a type, you secure the objects of that type, by definition, so omitting the term "type" in this context is "accurate enough".
• Consistency: How is the same concept treated in the context of the solutions? In addition the previous argument in favour of simplicity in the context of privileges may not apply in the "select rule" vs "select rule type" UI case (are these the only two places where this comes up?)

I would go for consistency and if it's entirely up to us, I would choose the simplest "accurate enough" language to surface on the UI.