Support enable/disable rules on request configuration rules

[offtherailz]

Description

requestsConfigurationRules (and legacy authenticationRules) currently apply unconditionally whenever a rule's urlPattern matches. There is no way to activate/deactivate a rule depending on runtime conditions such as the current user's groups or role. This makes it hard to attach different auth headers/params to the same URL pattern depending on who is logged in (e.g. only send a Bearer token for users belonging to a specific group).

Add support for an enabled property on each rule: either a plain boolean, or a plugin expression string using the same syntax already supported for cfg.disablePluginIf (e.g. state('usergroups'), includes(...), hasAtLeastOne(...)). Rules without enabled keep applying unconditionally, so the change is backward compatible.

Acceptance criteria

• Each entry in requestsConfigurationRules can declare an enabled property (boolean or expression string)
• Rules with enabled: false are skipped
• Rules with an expression string are evaluated against the monitored state (same mechanism as cfg.disablePluginIf), e.g. "{includes(state('usergroups'), 'editor')}"
• Rules without enabled keep the current behaviour (always applied)
• Legacy authenticationRules converted via convertAuthenticationRulesToRequestConfiguration also respect enabled
• Documentation updated in local-config.md
• Unit tests covering: no enabled property, enabled: false, expression resolving to true, expression resolving to false

Other useful information

Implemented in #12702.