Add create_signal_from_stream function

[sgued]

I think this is a better implementation of create_signal_from_tokio_channel:

• This implementation properly handles the effect callback being dropped (when the parent scope is disposed?) by dropping the stream
• This implementation does not need to spawn a new task, and therefore is runtime independant
• This implementation is generic over streams (including futures::channel::Receiver)
• This implementation avoids having the value wrapped in an Option (if no initial value is available, it is easy to map the stream to wrap values in a Some with StreamExt::map
• This implementation does not require the value to be Send

Overall is there a plan for async interop in floem? I wonder if I should implement an API like Leptos' resource API next.

• add example ( a version of the timer that instead uses a tokio stream)

• add test for the infinite loop case I'm worried about:
  Basically it's checking that using the following stream implementation in tokio-timer does not lead to an infinite loop, but I'm not sure how to make it into a test. It works with the current version, but I'm afraid that it would be possible that a future change to the reactive system could break this.

struct StreamWrapper {
    inner: IntervalStream,
    should_yield: bool,
}

impl Stream for StreamWrapper {
    type Item = Instant;
    fn poll_next(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Option<Instant>> {
        let mut this = self.as_mut();
        let should_yield = this.should_yield;
        let should_yield = mem::replace(&mut this.should_yield, !should_yield);
        if should_yield {
            cx.waker().wake_by_ref();
            return Poll::Pending;
        }

        Pin::new(&mut this.inner).poll_next(cx)
    }

    fn size_hint(&self) -> (usize, Option<usize>) {
        self.inner.size_hint()
    }
}

[dzhou121]

This does look really nice thanks!

As in async interop, I think that's desirable. And feel free to explore it.