There are seemingly no C#-side compile-time guarantees that it is safe,
but if the task's state is `Faulted` (as is checked right before), the
exception cannot be null as per the documentation.
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.
Silencing an exception from a task continuation requires accessing
`task.Exception` in any way, which was not done previously if
`logOnError` was false.
To resolve without having to worry whether the compiler will optimise
away a useless access or now, just always log, but switch the logging
level. The unimportant errors will be logged as debug and therefore
essentially silenced on release builds (but could still be potentially
useful in debugging).
