Support spawning futures

[dhardy]

#376 adds support for same-thread async methods. We could add direct support for spawning a closure resolving to a message, but there are a few details to resolve.

Spawn a single thread or use a thread-pool (with what size)? This depends on the intended use case.

Use a closure (like std::thread::spawn) or an async fn (like futures::executor::ThreadPool)? Either can be converted to the other easily enough so not too important.

Use the function's return value (with join) or a channel to receive messages? There is already an open question whether push_async should support multiple messages. Again, this partly depends on the use-case.

WidgetId, used to track the message-sending widget, is not currently Send, by design. It could be, by switching to atomic reference counting; alternatively we could store the id on the same thread along with a join handle / channel. Is it otherwise useful to make WidgetId: Send? If not it might be better not to do this (though given that most WidgetId values don't allocate anyway, it may not have an observable perf. impact).

ErasedMessage is not Send and does not require M: Send. We could add a variant/wrapper which is Send (and supports conversion to ErasedMessage).

[dhardy]

The PR was amended to include push_spawn, and this used to support async background rendering of the Canvas widget.