util/log: clean up and document the handling of stderr

[knz]

Required by #48051

Previous work in this area of the code introduced a confusion between
two orthogonal concepts:

• each logger might copy its log entries to the process' external
  stderr stream (e.g. the terminal during interactive use), as
  set by its "stderrThreshold" variable.

• direct writes by Go code to process-wide file descriptor 2 (such
  as done by the Go runtime) or os.Stderr (such as done
  by 3rd party packages when doing their own ad-hoc logging)
  can be redirected to a logger's output file.

The confusion (mostly mine - @knz) was to mix the two kinds of
"stderr" and mistakenly conflating "entries submitted to this logger
via API calls" and "direct writes to fd 2 by other go code without
looking at the logging API". These are actually completely separate
and independent concepts/mechanisms.

The code clarifies the situation as follows:

• the process' external stderr stream is always available via
  log.OrigStderr and this is meant to never change throughout
  execution.

• the external stderr stream is the sink for Shout() API calls
  and also the copy of log entries whose severity
  exceed the "stderrThreshold" variable.

• separately, at most one logger may redirect internal writes to fd
  2 and os.Stderr to its log file. This is determined by
  its variable "noRedirectInternalStderrWrites" (previously
  named "noRedirectStderr").

Beyond this, this commit fixes 3 bugs.

1. the code was intending to both redirect the standard stderr file
   descriptor (fd 2 on unix, error handle on windows) and also
   os.Stderr separately, but failing to do so on unix build targets.
   It was done correctly for windows. This is now corrected so that
   os.Stderr gets assigned on all targets.

   (The separate assignment of os.Stderr is necessary because
   although Go intializes this to be equivalent to the standard
   file descriptor upon process startup, other Go code can
   assign os.Stderr after initialization.)

2. upon encountering a write error to its output file, a logger
   would previously report that write error twice to the
   process' external stderr. This has been corrected
   so that the write error is only reported once.

3. previously, upon a log.Fatal performed while configuration would not
   otherwise cause a copy the F entry go to the process external stderr,
   the code would override the configuration and force a copy of the
   entry to the external stderr stream.

   There is no good reason for this - either the user wants F entries
   on the external stderr and signal this desire via
   --logtostderr=FATAL or lower, or they don't want F entries there
   at all via --logtostderr=NONE. There is no reason for an
   override and the code should honor the configuration.

   (I introduced the bug together with the confusion mentioned
   at the beginning.)

Release note: None

[cockroach-teamcity]

This change is 

[knz]

ok this has overcome TC at last. RFAL

[tbg]

Reviewed 14 of 14 files at r1, 4 of 4 files at r2.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @bdarnell)

[knz]

thanks

bors r=tbg

[craig]

Build failed

• GitHub CI (Cockroach)

[knz]

bors r=tbg

[craig]

Build succeeded

• GitHub CI (Cockroach)