🐭 Add mouse buttons to mouse event args

[tomrijnbeek]

✨ What's this?

This PR updates the MouseEventArgs to include the currently held down mouse buttons in the same way as we pass in the modifier keys.

🔗 Relationships

Provides a helpful step towards #5

🔍 Why do we want this?

After looking into how to implement drag and drop, I decided to investigate how WPF does it, which basically lets controls themselves decide when a drag starts (this because very few controls actually need to support it). So what we want to be able to do is in the OnMouseMoved handler check whether the mouse button was pressed while moving the mouse, as this is a pretty good indication we're starting a drag.

Problem is: right now we can't.

This PR makes the change to include this information in each of the MouseEventArgs objects so that this information becomes available.

🏗 How is it done?

The MouseButtons struct follows the ModifierKeys struct structure very closely, and works in a similar way. This is then passed into the MouseEventArgs, which also acts as base class for all other mouse event args.

💥 Breaking changes

The constructors of the mouse event args are public, and they now require an extra parameter, so all previous calls are broken. I considered adding a constructor overload, but I feel it is weird that MouseButtons would be optional.

🔬 Why not another way?

It may be considered weird that MouseButtons is present in even the MouseClickEventArgs, but it opens up the option of responding to "left and right" click at the same time, and same for scrolling. If we wanted to limit the MouseButtons to the OnMouseMoved event, we would have to either introduce a new MouseMoveEventArgs, which would break all existing overrides of that method (much bigger breaking change), or we would remove the MouseEventArgs as base class of the other two, which would also have unintended side effects.

[paulcscharf]

Not a record?

[tomrijnbeek]

I wanted to keep the constructor private (in line with the modifier keys), which is not something you can do with records. The constructor parameters are very non-expressive, so having the builder methods to build the object instead makes much more readable code. So yeah... record would be nice if they allowed private constructors, but unfortunately there will always be a positional constructor.

[paulcscharf]

Understood!