Support sending async messages

[dhardy]

This renames EventMgr::push_msg to push, and adds support for futures resolving to a message:

pub fn push_async<Fut, Out>(&mut self, id: WidgetId, fut: Fut)
    where
        Fut: IntoFuture<Output = Option<Out>> + 'static,
        Out: Debug + 'static,
{ ... }

The future is run on the same thread (thus should not have high CPU usage).

Currently, it is required to identify the sending widget (id) explicitly and the future is not polled immediately. This might change if the EventMgr context tracks the current widget (WidgetId).

PR also includes changes to event handling. Most notably, handle_message may now be called on the widget which submitted the message (important for async rendering in Canvas using this async impl, but also useful for several other cases).

The Canvas widget now uses async rendering. It is possible to observe that a resize initially scales the old result, then re-renders. I'd like to do the same for Svg, but usvg::Tree is neither Send nor Sync so we can't push the work to another thread (without unsafe or other ugly workarounds).

[dhardy]

Status:

• Canvas uses async drawing..
• ..but there appears to be some scheduling bug (image is only updated when a new event such as mouse movement is received)
• Svg cannot (safely) use async code since the tree cannot be moved to another thread

[dhardy]

Status: two bug fixes and some other tweaks.

The animation is still broken on X11 but works on Wayland, so possibly a winit issue (more investigation needed).

[dhardy]

Status: fixed. Futures are now polled at the end of both event-processing and drawing operations (including futures pushed during this processing). This ensures futures using background threads or IO can start before the event loop sleeps.