Merge KeyEventExtra into KeyEvent

[madsmtm]

To make the text_with_all_modifiers and key_without_modifiers fields easier to use, and to allow constructing KeyEvent in user test code. This also removes the need for KeyEventExtModifierSupplement.

Fixes #3606 (which is desired by Xilem/Masonry).

I went with adding the fields on all platforms, and just defining their behaviour as the same as text/logical_key on the unsupported platforms. This is similar to how we have all WindowEvents available on all the platforms, but not all are emitted by all of them, so I felt this was a good trade-off.

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality

[madsmtm]

Another option would be to make this an Option<keyboard::Key>, I'm not familiar enough with it to say what would be best.

[madsmtm]

Another option would be to always set None here on these platforms, but I felt this choice was more consistent with key_without_modifiers (unless we change that to be an Option).

[kchibisov]

Could we have it the same way as before in a struct on a KeyboardEvent which you can not match, but can e.g. default init or set separately?

I don't really want to have an option to match on those, since they are not cross platform. Other than that removing the extension is fine and it's not that big of a breaking change.

[madsmtm]

Could we have it the same way as before in a struct on a KeyboardEvent which you can not match, but can e.g. default init or set separately?

Hmm, I can, but I kinda feel like that'd just be unnecessary indirection? And I guess it we really want users to be able to test their crates, they'll need the ability to set the fields in this extra struct anyhow?

I don't really want to have an option to match on those, since they are not cross platform. Other than that removing the extension is fine and it's not that big of a breaking change.

Am I understanding correctly that your worry is that users may be more aware of a method not being cross-platform, as opposed to a field being so?

[kchibisov]

Yes, so it's an Option and you should account for it explicitly. If it's not an option you will kind of assume that it works, where on e.g. some it'll always fail. You can just default initialize it, I don't see an issue with it. Yes you won't be able to test the values you have in text_with_all_modifiers, but you write the keys yourself, so can write whatever in regular fields, so it doesn't really matter.