`MouseScrollUnit` handling is unprincipled and inconsistent

[alice-i-cecile]

Problem

Bevy's MouseScrollUnit enum has two values, inherited from winit: Pixel and Line. The ratio between physical mouse movement and reported values is inconsistent across OSes. In some cases, a single click of the mouse wheel may be equal to 1 line or 14 pixels. In other cases, it varies, and I haven't been able to track down good documentation on this.

When responding to these changes, most users should attempt to have consistent values regardless of which enum value is active. Zooming your camera out by a fixed number of lines makes no sense. We have a constant for that at SCROLL_UNIT_CONVERSION_FACTOR, but this is a) not used throughout the engine and b) only a heuristic

The exception here is genuinely text-like variants: text, maybe lists. Those should respect the setting, and scroll an equivalent number of lines.

Proposed solution

1. Move this value to a resource to make it dyamically configurable.
2. Audit internal uses and always access that resource value.

Future work

Find some way to check this from the OS, and prepopulate that resource with that value. Feature-gate that if it introduces additional dependencies: this is a very minor concern.

This appears to be platform-specific in complex ways. 3 should definitely be left to its own PR, and there's a very real chance that the actual fix for it is upstream in winit. My research suggests that there's two conversion steps here: notches -> lines, and lines -> pixels.

We may actually want to cut the MouseScrollUnit out completely, and only report a single normalized value, while having a separate message stream for completely raw values.

Previous discussions: rust-windowing/winit#3493, #5823.

[alice-i-cecile]

cc @Shatur; we've looked into this together in the past.

[stevehello166]

I can work on this

[alice-i-cecile]

Lovely. Just tackle the first two points for now please :)

[MyCodingSpace5]

@alice-i-cecile by an resource do you mean like an handler which will keep track of the object's lifecycle or something which the handler itself can be configured?