SshCommand: OutputStream & ExtendedOutputStream should only return 0 when channel is closed

[drieseng]

Invoking Read(Byte[], Int32, Int32) on SshCommand*'s OutputStream or ExtendedOutputStream should blocking until either data is available, or the channel is closed (in which case zero should be returned).

We should strongly consider applying breaking changes to the SshCommand API as well:

• Change signature of public string Execute() to public void Execute().
• Have ExitCode throw when we have not received an ExitStatusRequestInfo.
• Remove the Result property (users should use OutputStream instead).
• Remove the Error property (users should use ExtendedOutputStream instead).

[drieseng]

I've disabled the Ssh_Command_IntermittendOutput_OutputStream() integration test due to this issue.

[lucastheisen]

It would be nice to simply be allowed to supply our own streams (like ProcessStartInfo for all in/out/err). Especially now that net core has System.IO.Pipelines. I think the internal PipeStream could probably be replaced altogether. It would certainly reduce the element of surprise...

[IgorMilavec]

Just made a similar argument about API cleanup in #931... :) What if we also removed/deprecated the ExitCode property and return the exit code from Execute/ExecuteAsync?