Add buffering to stdout

[n-milo]

This PR includes implementing IsTerminal for the raw sys::stdio structs, so we can check terminal status without constructing an Stdout object.

Then Stdout switches from wrapping a LineWriter to a StdoutWriter, which wraps either a LineWriter or BufWriter depending on whether or not stdout is pointing to a terminal. This means standard output will no longer be line-buffered when outputting to a non-terminal.

We could also make stdout wrap a dyn Write instead of the StdoutWriter enum, which would make it simpler but I figured we don't want dynamic dispatch for every write to stdout.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joshtriplett (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[joshtriplett]

The first three commits LGTM.

The remainder will need an FCP to change behavior.

[the8472]

This touches on two topics

A) Is it ok to hand out file borrowed descriptors that violate the locks? #114140
Until that question is resolved we shouldn't expose them. And we can't add those APIs unstably since they're trait implementations.

B) Blockbuffering for stdout. #60673 and #78515 (comment)
I think this requires more complex API changes because a user may still want line-buffering even when writing to a pipe for example because the pipe connects to a parent processes that interleaves multiple children to a terminal. Switching to block buffering may then end up tearing line endings or delay the output more than it currently does. So they user would at least need an API to switch back to line-buffering. Implementing such an API is what the linked issues are about.

[m-ou-se]

Changing the block buffering behaviour for stdout should be done in two steps:

1. Add an API for switching buffering mode for stdout (line, block, none). That way, Rust programs can opt-in to block buffering.
2. Change the default behaviour to block buffering when the output is not a tty. Then, Rust programs can still opt-out using the API from step 1.

I am personally not convinced (yet?) we should actually do step 2, but we all seem to be in favour of at least taking step 1. Step 2 can be a separate discussion.

For step 1, we'd first need to see a proposal for an API for this. Several ideas have come up in the past, including adding a new 'switchable buffer/writer' type to std::io, adding a line buffering mode to BufWriter, adding a block buffering mode to LineWriter, adding a std::io::set_stdio_mode function taking an enum, and probably a few more ideas.

See also #78515 (comment)

I personally think that adding a block buffering mode to LineWriter (and exposing that on Stdout too) is the cleanest solution, but am open to other solutions as well.

[bors]

☔ The latest upstream changes (presumably #120365) made this pull request unmergeable. Please resolve the merge conflicts.

[joshtriplett]

r? libs-api

[m-ou-se]

Closing this because of #115652 (comment). Feel free to propose an API for step 1 to get things moving. Thanks!