I don't see an issue with applying this workaround to more places, even
though it is a workaround, because it marks each usage very clearly. If
we design a better solution in the future it should be easy to replace
the usages.
Until now, the implementation of the overrides in `SelectionBlueprint`
have been confusing to the point where I would just implement by
trial-and-error (or copying from an existing implementation). This was
due to a combination of using "object" space coordinates
(ie. the thing the `Blueprint` is operating on) and screen-space coordinates.
This change switches all event related coordinates to screen-space,
which is how we already handle rotation/scale operations. With the
introduction of other editor types where the related objects are
drawables, this also makes a lot more sense.