feat: Add BoxSelection callin and logic

[badosu]

No description provided.

[sprunk]

Does this happen continuously as you drag? If yes, is there a way to distinguish "this is not yet the final box and is part of a drag, more events might come later" vs "this is the final box, the user released the mouse"? (Checking the state of the mouse button might be a decent workaround for now but I'm not sure whether that's 100% reliable.)

[badosu]

This is intended only for the event for mouserelease, but I think it would make sense to have a continuous callin for certain features. SmartSelect in particular would benefit from it. The aforementioned PR in particular is less ambitious in this regard, as I'm addressing the most egregious issue (being able to minimally handle external box selection, without having to deal with engine propagated events we want to ignore and not needing to take over mouseowner for such).

But I think it would make sense for a more complete design to have something such as BoxSelectionMove(anchorx, anchory, pivotx, pivoty, dx, dy), BoxSelection(anchorx, anchory, pivotx, pivoty).

At the moment, being able to handle dynamic selection (logic without release) requires using Update calls, which is very much non-ideal, and would still be present without BoxSelectionMove.

[badosu]

@sprunk We can discuss design here. This PR is just a very raw poc.

[badosu]

Closed for now to prioritize proper SelectionChanged callin as a replacement for LayoutButtons. I might revisit this in the future.