Issue title: Subscription should have a flat_map
 Issue body: I just encountered a situation where I would like to produce three distinct events that are also produced by buttons when I get one of three keypresses. To support this, I made my message an Option:

```rust
type Message = Option<Message>;
```

I think an easier approach would be to support flat_map on `Subscription`. Right now, `Subscription` has a method [`map`](https://docs.rs/iced_futures/0.1.2/iced_futures/subscription/struct.Subscription.html#method.map). This method is useful to convert to events, but some subscriptions might lead to several events being produced or no events being produced. Currently, I see no API to accommodate that. I think we should add a `flat_map` method to `Subscription`. This would allow us to return anything that impls `IntoIterator` from `flat_map` and produce a new subscription that flattens the iterator. An example should be provided that uses a `flat_map` with `Option` so people are aware that is possible (many don't know `Option` impls `IntoIterator`).

I am willing to set up a PR for this if this makes sense. Just let me know.
 Comments: 
 Comment 0: I am not convinced we should complicate the subscriptions API to potentially allow combinators with complex logic.

A `Subscription` always produces messages with a given contract. I find it's easier to think about them this way. Then, your `update` logic can choose to handle the relevant messages and ignore the others. I find this forces users to keep message logic centralized in a single place.
{'source': 'GithubIssues', 'repo_name_with_owner': 'hecrj/iced', 'issue_id': 610806352, 'repo_stars': 11081.0}