replace IConsole with two TextWriters in Configuration

[adamsitnik]

The whole idea behind this PR is to move IConsole to Rendering and extend the Config with two mutable TextWriter properties (Out and Error). Both properties are lazy initialized (perf), with default values of Console.Out and Console.Error. To test the produced output, they can be preconfigured with StringWriter instances. To disable the ouput, they can be set to TextWriter.Null.

/// <summary>
/// The standard output. Used by Help and other facilities that write non-error information.
/// By default it's set to <see cref="Console.Out"/>.
/// For testing purposes, it can be set to a new instance of <see cref="StringWriter"/>.
/// If you want to disable the output, please set it to <see cref="TextWriter.Null"/>.
/// </summary>
public TextWriter Out
{ 
    get => _output ??= Console.Out;
    set => _output = value ?? throw new ArgumentNullException(nameof(value), "Use TextWriter.Null to disable the output");
}

/// <summary>
/// The standard error. Used for printing error information like parse errors.
/// By default it's set to <see cref="Console.Error"/>.
/// For testing purposes, it can be set to a new instance of <see cref="StringWriter"/>.
/// </summary>
public TextWriter Error
{
    get => _error ??= Console.Error;
    set => _error = value ?? throw new ArgumentNullException(nameof(value), "Use TextWriter.Null to disable the output");
}

contributes to #1905, it's a first step towards making configuration mutable

[jonsequitur]

The names Error and Out might need a little more context unless we're also renaming CommandLineConfiguration, e.g. ConsoleOut and ConsoleError.

[tmds]

The whole idea behind this PR is to move IConsole to Rendering and extend the Config with two mutable TextWriter properties (Out and Error).

    public interface IConsole :
        IStandardOut,
        IStandardError,
        IStandardIn

@adamsitnik @jonsequitur how does standard input fit into this?

[jonsequitur]

We never arrived at a satisfactory design for these interfaces. We decided it's safest to leave it out of scope for now.

[tmds]

That makes sense. My main rule of API design: when in doubt, leave it out.

This seems somewhat awkward:

parseResult.Configuration.Output.WriteLine("Hello");

[jonsequitur]

It is a little awkward. We're working on how to better separate parser configuration from invocation-related concerns. Suggestions are welcome.