Futures-rs: Make more of futures-utils dependencies optional

[seanmonstar]

The futures-util crate provides a whole bunch of extra goodies. A user may wish to be able to use FutureExt or StreamExt, without most of the other goodies. It'd help with compilations if we could disable those pieces.

• futures-channel is used for RemoteHandle (just checking, does this type still pull its weight)?
• futures-sink and futures-io might not always be necessary.
• futures-select-macro includes some heavy dependencies itself, and if we don't use the macro, we could save much here (and could prevent needing to compile rand as well). The select macro is already optional, but is required if the async_await feature is enabled.

[Nemo157]

RemoteHandle is used for SpawnExt::spawn_with_handle, which _seems_ like something very useful to use (although I don’t recall seeing any usage in the wild).

[seanmonstar]

Oh yea, spawn handle is useful!

Hrm, I still think being able to only include FutureExt and StreamExt is useful (I have some smaller libs that don't need other things). We could make that SpawnExt method optional... Or put the functionality directly in futures-channel...

[taiki-e]

• futures-select-macro includes some heavy dependencies itself, and if we don't use the macro, we could save much here (and could prevent needing to compile rand as well). The select macro is already optional, but is required if the async_await feature is enabled.

This resolves #1489.

[taiki-e]

Well, I like this as a whole. And I think it is preferable that the impact of this will only stay on futures-util-preview without appearing on futures-preview.

• Using futures-util-preview, we can finer control over dependencies. This is probably especially important for library developers.
• Using futures-preview, we can easily access many useful features. We don't have to care about complex feature gates.

What I care about here is which features should be included in futures-util-preview's defaults, but I have no strong opinion on this.

Also, I think we should check that compilation does not fail due to the combination of feature gates.