Primarily use ButtonPress and ButtonRelease for mouse events

[MarcusGrass]

• [x] Tested on all platforms changed
• [x] Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• [x] ~~Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior~~
• [x] ~~Created or updated an example program if it would help users understand this functionality~~
• [x] ~~Updated feature matrix, if new features were added or implemented~~

(Sorry for the weird PR spam)

This change makes ButtonPresses like KeyPresses use regular events instead of XI-events which allows the scroll-button to be grabbed, the reason for wanting to do this is stated in https://github.com/rust-windowing/winit/issues/2359.

If I understood what's happening here correctly, and I might not have: You cannot grab XI_Button events and still get regular Button events. XI uses motion for scrolling and doesn't count scrolling as a button press. This leads to the problem where you can't grab scroll-keys as they aren't registered as being pressed when scrolling happens.

This change modifies that to make winit use regular ButtonPressEvents for scrolling and stops it listening for XI_Button events. Interestingly there already was logic implemented for scrolling using buttons, but because XI doesn't count scrolling as buttons that logic was never activated, it's now used in the regular ButtonPress handling instead.

For extension devices not targeting the core-pointer scrolling behaviour should be the same, although that's hard to test.

Tested on x11 and now MouseWheel events only arrive if not grabbed. Additionally tested building glutin and then alacritty on top of this change and the problem is gone.

[notgull]

Is there information lost when moving from XIButtonPress to xproto's ButtonPress? That would be my main worry with this PR. Why can't xinput grab the scroll button?