X__stderrp, the symbol ccgo-generated code links C stderr against on these
ports, was initialised from Xstdout instead of Xstderr. That FILE's F_file
is 1, so every stdio entry point handed fd 1 to fwrite and fprintf(stderr,
...) ended up in os.Stdout.Write. Introduced with the darwin port in
5f1e2579 (2020-11-26) and copied verbatim into the three later BSD ports.

netbsd is unaffected in practice - ccgo emits &X__sF[2] there, which is
correct - but the wrong line is fixed too so that libc's two exported
spellings of stderr agree on the ports that have both. openbsd is affected
indirectly, via consumers that seed their own ___stderr from X__stderrp.
Nothing in the musl/linux or windows path changes.

Adds TestStdioBinding, which pins all three of X__std{in,out,err}p. The
failure mode is invisible to a build and to every other test, and "copied
wrong" is how it reached three of the four ports.

Downstream: on these eight targets a transpiled C program's stderr text
previously arrived interleaved into its stdout, so expected-output fixtures
recorded there may need updating. Capturing C stderr in-process now needs
fd-level redirection, as it already does for every descriptor but 1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>