Add support for separate encodings for stdin, stdout, and stderr

[gnodet]

• Add new methods to Terminal interface: stdinEncoding(), stdoutEncoding(), stderrEncoding()
• Update TerminalBuilder to support separate encodings
• Add support for standard Java system properties: stdin.encoding, stdout.encoding, stderr.encoding
• Add unit tests to verify encoding functionality

Fixes #1282

[vy]

@gnodet, thanks so much for the lightening fast fix. 💯

Judging from the JavaDoc, I'm struggling to understand the relation between encoding and std{in,out,err}Encoding parameters:

1. What is actually meant by "general character encoding to use"? I mean, if it won't be used for std{in,out,err}, what will it be used for?
2. Is encoding a fallback for std{in,out,err}Encoding? If so, what happens when both are provided?
3. Which of the encoding and std{in,out,err}Encoding variables are nullable?

I'd appreciate it if you can help with the above questions.

[gnodet]

@gnodet, thanks so much for the lightening fast fix. 💯

Judging from the JavaDoc, I'm struggling to understand the relation between encoding and std{in,out,err}Encoding parameters:

1. What is actually meant by "general character encoding to use"? I mean, if it won't be used for std{in,out,err}, what will it be used for?
2. Is encoding a fallback for std{in,out,err}Encoding? If so, what happens when both are provided?
3. Which of the encoding and std{in,out,err}Encoding variables are nullable?

I'd appreciate it if you can help with the above questions.

When building the actual terminal, you should end up with the following:

        this.encoding = encoding != null ? encoding : Charset.defaultCharset();
        this.stdinEncoding = stdinEncoding != null ? stdinEncoding : this.encoding;
        this.stdoutEncoding = stdoutEncoding != null ? stdoutEncoding : this.encoding;
        this.stderrEncoding = stderrEncoding != null ? stderrEncoding : this.encoding;

So all are nullable, and encoding is a fallback.

However, the detection is done in the TerminalBuilder. For stdin, the computation is:

• use stdinEncoding field if specified
• else use org.jline.terminal.stdin.encoding system property if specified
• else use stdin.encoding system property if specified
• else use the computed general encoding

The general encoding is computed as follows:

• use encoding field if specified
• else use org.jline.terminal.encoding system property if specified
• else use codepage field to compute the encoding if specified
• else use org.jline.terminal.codepage system property to compute the encoding if specified
• else use UTF-8

So the general encoding, stdin, stdout and stderr, as computed above, are given to the TerminalProvider to actually build the terminal.

[vy]

Thanks so much for the elaborate response. 🙇
I have a few more questions, if I may:

1. Can encoding be used for anything else than std{in,out,err} encoding? If not, would it be possible to deprecate/remove it completely?
2. Shouldn't MouseSupport::readExt(Terminal) use terminal.stdinEncoding() instead?
3. Shouldn't AnsiConsole::ansiStream(boolean) use terminal.std{out,err}Encoding() instead?