Improve accelerator detection and shortcut behavior of mnemonics
MnemonicShortcut is the new central component to manage mnemonic shortcuts of controls which can benefit from it. MnemonicShortcut mimics behavior of a control that was assigned a QQC2.Action. Exposed API is barely enough to cover all the conditional expressions, emit all the same signals, and trigger property writes from native code without breaking any bindings.
The new behavior is that in absence of an action object, checkable buttons will now emit Action::triggered() signal before AbstractButtonButton::clicked.
Old behavior is that they did not emit action.triggered() at all. All of this is still suboptimal, as we don't get to propagate toggled() signal when it would've been seemingly appropriate, so downstream components should not rely on this signal handler (such as SessionButton in Plasma SDDM theme). But at least we are now consistent with QQC2.Action shortcuts! So there's that. Hook to Action::onTriggered, and nave a nice day.
Hopefully, someday we would be able to use this central component follow system preference on whether to use and show mnemonics at all. Currently such setting is implemented at Breeze application style level, which is quite specific and not generic at all.
The new regular expression is much more robust than the old one which failed to handle even the basic cases which it was supposed to. However, it still feels wrong to even have to resort to a regex here in the first place. Maybe we could reuse algorithms from native code in Kirigami.MnemonicData class?
There is still confusion, however, between org.kde.desktop QQC2 style bridge, Breeze QStyle implementation, Kirigami and QtQuick.Controls as to who is responsible for what. Which is a common reason why mnemonics sometimes not showing up with their underlines or not getting triggered on shortcut. This is a can of worms, and needs fixing on multiple levels.
Note 1: It is possible to turn off an auto-exclusive radio buttons (i.e. those that share parent with other radios, but does not bind explicitly to any ButtonGroup). But auto-exclusive Radios do behave weird even without this style implementation, so just stay safe and always specify a ButtonGroup.
Note 2: Most of things here get overridden by Kirigami.FormLayout magic anyway.
oh, and also fix whitespaces, explicit signal handlers, and import aliases