Replace SftpFileStream with Stream in ISftpClient method signatures.

[doxxx]

I'm opening this PR to initiate discussion around solutions for #1691. The solution implemented here solves #1691 because it is relatively easy to mock a method that returns Stream. However, this solution prevents access to the Timeout property of SftpFileStream. It is also not binary-backwards-compatible but somewhat source-backwards-compatible.

[Rob-Hague]

Thanks for the PR. My thoughts are basically the same as in #1508 - that changing popular public API for the sake of mocking is just not worth it at this point.

The impact of this one could potentially be lessened by changing only the interface and explicitly implementing the methods on the concrete client, but I'd still not really be convinced

[doxxx]

Do you have any suggestions for how to solve the mocking issue? Right now the only viable solution is #1691 (comment), which is not terrible but still a little sad that it's necessary.

[Rob-Hague]

IMO the wrapper is totally valid since it provides the most control and flexibility. I think it would be the same approach as that in which one wanted to mock a component that called methods on System.IO.File, or System.Net.Http.HttpClient etc.