Custom futures executor with iced_futures

[hecrj]

Fixes #63.

Mainly, this PR introduces a configurable Executor associated type to Application by leveraging a new subcrate: iced_futures.

The Executor trait

The new iced_futures subcrate contains a new Executor trait which is meant to allow shells to use different runtimes in a generic way.

Feature flags can be enabled to obtain an implementation of this trait for well-known executors (thread-pool, tokio, async-std, and wasm-bindgen-futures for now). This allows users to easily opt-in and choose their preferred runtime.

For instance, let's say we want to use a tokio runtime for our Application. We simply add iced_futures to our dependencies and enable the tokio feature:

iced_futures = { version = "0.1.0-alpha", features = ["tokio"] }

And we just plug it into our Application:

impl Application for Example {
    type Executor = iced_futures::executor::Tokio;

    // ...
}

For convenience, iced provides an executor::Default which should resolve to

• a ThreadPool in native platforms.
• an executor based on wasm-bindgen-futures in the Web.

This basically replicates the behavior until now. Of course, if you choose to use your own executor, then it's up to you to ensure things stay cross-platform.

Additional amenities

The new subcrate also includes a bunch of new useful types:

• A subscription::Tracker, which can be used to track a Subscription, spawn or close streams accordingly, and broadcast shell events.
• A batteries-included Runtime, combining an Executor and a subscription::Tracker. It can be used to easily spawn commands or run event subscriptions and get notified of the results!
• The old Command and Subscription types, which have been moved from iced_core.

Self-contained examples

The dev-dependencies of iced were getting out of hand. Most of the examples are very different and showcase distinct ways to use the library while combining it with other parts of the ecosystem.

Because of this, it made sense to turn every example into a subcrate. As a consequence:

• iced has no dev-dependencies now! 🎉
• The dependencies of an example are more explicit and clearer, which in turn makes the examples easier to understand, copy, and extend.
• Compiling a specific example doesn't require all the other example dependencies. This is important because the tour (the main featured example) only depends on iced and env_logger.
• Each example can have its own README with a nice description and a GIF (I haven't recorded GIFs for all the examples yet!).
• We can build complex examples with multiple modules and showcase how to scale Iced applications.