futures-rs: `SinkExt::send` and `send_all`, and `StreamExt::next` should not need `Self: Unpin`

I kind of agree that the existing method should still exist, what I argue is for it to exist under another name, so that the most obvious name is also the 0-cost one, to try and follow Rust’s philosophy. Hence my suggestion of making send & co. take Pin<&mut Self> without requiring Self: Unpin and to add a send_unpin that does require Self: Unpin like:

fn send_unpin(&mut self, item: Item) -> Send<Self, Item> {
    Pin::new(&mut self).send(item)
}

As for the stream generated by #[async_stream], if it is like futures then it will be !Unpin as soon as a borrow will live across an await point, which will quite likely be pretty often (after all that’s exactly the reason why Pin was introduced in the first place, though other use cases also called for it)

It still adds code-readability overhead

await!(sink.send(foo))?;
let bar = process(await!(stream.next())?);
await!(sink.send(bar))?;

vs

await!(Pin::new(&mut sink).send(foo))?;
let bar = process(await!(Pin::new(&mut stream).next())?);
await!(Pin::new(&mut sink).send(bar))?;

or

let (sink, stream) = (Pin::new(&mut sink), Pin::new(&mut stream));
await!(sink.as_mut().send(foo))?;
let bar = process(await!(stream.as_mut().next())?);
await!(sink.as_mut().send(bar))?;

The majority of concrete Sinks are likely to be Unpin, and when working with generic sinks you will commonly want to request an Unpin sink and push the pinning requirement up to your callers (it will probably be worth having some guidelines around when you want to have + Unpin and when you should stack-pin yourself once there’s more familiarity with which is better).