watch::Receiver and broadcast::Receiver cannot be composed

[vojtechkral]

Is your feature request related to a problem? Please describe.
In our codebase we have some Futures implemented on top of watch::Receiver. This works fine in 0.2 as watch::Receiver implemented Stream, which could be delegated to.
But now there's only one async fn (changed()) which can't be polled over in a Future implementation (unless the resulting opaque future is boxed up and stored, which seems hacky).

Describe the solution you'd like
Not sure, maybe reinstate the Stream implementation? Or, in fact, maybe just a function to register a Context would suffice... Doesn't really matter to me as long as the API can be used from Future::poll().

Describe alternatives you've considered
I looked if I could use broadcast instead, but in fact there's the same problem, it also only exposes opaque Future/Stream types.

[Darksonn]

There is a good reason related to the internal implementation for this, however it would be possible to expose an into_stream for Watch like there is for broadcast, and it would be possible to make those non-opaque types. The streams would be !Unpin due to the internal implementation details I mentioned.

One option is to add a Stream convenience like we're doing with mpsc sender in #3105.

[theduke]

It seems like this is now implemented with the WatchStream wrapper, correct?

If so this could be closed.