add support for Console.In to IConsole

[jonsequitur]

[jnm2]

This would be nice so that I don't have to mix calls to IConsole.Out.WriteLine and Console.ReadLine.

Would you consider IConsole.In.ReadPassword()?

I have an implementation that (when interactive) sniffs the console's current font to see if it has characters for the Windows password char (\u25CF, works with Consolas), falling back to '\u2022', \a (works on Terminal which used to be the default Windows console font), or *, in that order. Then it sets and replaces the console encoding if necessary. Probably the best thing would be to make this pay-for-play and have the user specify which character to use.

Then, it shows this character as the user edits. When the user presses enter, the displayed password length changes to ten.

If stdin is redirected, it just echoes ten dots after the line is read.

[hartmannr76]

@jonsequitur would you imagine it looking something like this? hartmannr76@17f0f18

This is my first time tinkering in these repo's so I just want to make sure the interface and added methods look 🆗 before I start adding tests to work with it.

This functionality would be helpful to read in additional arguments passed in via the cli (which is why I wanted to tackle this)

[jonsequitur]

Thanks, @hartmannr76. ReadLine and ReadToEnd seem like extension methods to me. They'll be useful and people will expect them, so it's good to include them, but perhaps not on the interface itself. One of the motivations for defining these IStandardStream interfaces was to restrict the surface area a bit from the existing TextReader and TextWriter types, especially with regard to overloads taking various non-string types, so that this kind of thing will work: https://github.com/dotnet/command-line-api/blob/master/src/System.CommandLine.Rendering.Tests/Example_TOP.cs#L75

So what is a good common case between these methods?

There's probably also a discussion to be had about whether these should use PipeReader and PipeWriter.