Return streams from `getStdOut`, `getStdIn`, and `getStdErr`

[jayschwa]

In the Zig codebase (and in my own, what little that is), almost every call to these functions immediately performs [in|out]Stream().stream. If getStdOut and friends just returned the streams directly, that would probably DRY a lot of code. Perhaps getStdOutFile could be added for less common use-cases.

Exceptions I found in Zig codebase:

• stdout_file.write() in a couple places, but OutStream has write too.
• cat_file in a test takes fs.Files, but it looks like it's implementation is only concerned with a read and write method on its arguments, and would probably not be hard to change.

[andrewrk]

If we provided global storage for stdio streams, it should probably be a buffered one, with a mutex protecting it. And then we'd probably want some hook to detect unflushed data after main(). This would match stdin, stdout, stderr from libc. My only concern with this is that an application generally should be in control of its own standard I/O streams, and I don't want this to be an invitation to libraries to start dumping garbage into stdio. That's what #2586 is for.

And then the buffering and the mutex might not actually be necessary, depending on how the application is structured. The code to detect unflushed data after main() would be nonzero cost, and nontrivial to figure out how to do it in all situations, e.g. a static library that does not link libc. The boilerplate is annoying, but it makes it clear that it's up to the application how it wants to deal with stdio.