either dependency is non-optional for futures-util

[Nemo157]

While doing #1151 I noticed that futures-util has a non-optional dependency on either. It would be good to make this optional and enable the futures-core and futures-sink features when enabled, but that's impossible to do without using a different feature name like use_either because of Cargo's interaction between optional dependencies and features. Once rust-lang/cargo#5753 is fixed it may be possible to use a renamed dependency in futures-util to get around this, but that seems pretty hacky. There has been some work on this in Cargo: rust-lang/cargo#1286 and rust-lang/cargo#5565, hopefully there'll be a nicer solution soon.

[MajorBreakfast]

I don't really like that futures-core depends on the either crate so it can define a Stream impl on Either. This should be the other way around: The either crate should have a feature that adds a Future/Stream impl. We already had to remove the Future impl for Either when Future was put into libcore. We should do the same for Stream for consistency. Also, if the either crate ever decided to unconditionally implement Unpin on Either, our Stream impl would instantly become unsound.