Functionally equivalent right now, but the combined variant is more
localised to what it actually needs to do, and less error-prone if
any new code gets appended to the method.
Until now, toolbox scroll areas would block input from arriving behind
them, even when no visible element was clicked.
In addition, clicking on a button inside a toolbox would still send a
`MouseDown` event to things behind it. Specifically, the editor's
`HitObjectComposer` would receive these events and also place objects
when the user does not expect them to be placed.
This fixes another regression that occurred due to `ScrollContainer`s no
longer blocking input theirselves.
Alternate method is to expose a `SnapDistancesChanged` event in
`IPositionSnapProvider` instead, but I chose this way as an analogue to
`IBeatSnapProvider.BeatDivisor`, which might even make sense to be
exposed as `BindableBeatDivisor` instead of caching that separately.
While osu!catch also implements a distance snap grid, it doesn't rely on
`GetBeatSnapDistanceAt` (unlike osu!), therefore it can't have the
"distance spacing" multiplier yet.
This has come up multiple times, with mappers citing that they have
muscle memory for mapping based on the centre of the playfield being in
the centre of the window.
The original plan was to have a second toolbar on the right hand side of
the screen to balance the padding, but we're not at that point yet.
Easiest solution is to do what stable does and allow the left-hand
toolbar items to overlap the playfield underneath it.
In edge cases where the user is running at an aspect ratio that causes
overlaps, they can choose to collapse the toolbars down. We can probably
work on this UI/UX a bit more as we update designs to be more friendly
to such cases.
