This change upstreams a number of changes since the last package update.

In particular this adds:

- New exported APIs (see godoc for further details):
  - glog.VDepth
  - glog.InfoDepthf
  - glog.WarningDepthf
  - glog.ErrorDepthf
  - glog.FatalDepthf
  - glog.ExitDepthf
  - glog.Names
  - glog.NewStandardLogger
  - glog.Verbose.InfoDepth
  - glog.Verbose.InfoDepthf
  - glog.ErrNoLog

- The -log_backtrace_at flag accepts now a comma-separated list of file:line locations.

- The -vmodule flag accepts a new syntax to match the full path to a module instead of just the module name. See the updated package documentation.

- A new internal/logsink package to support other outputs than files. Note: This package is internal, because we cannot guarantee at this point that the API remains stable.

More details at go/log-vs-glog (google-internal).

This was raised in #53.

cl/514318873 (google-internal)

The flag package ensures that the zero value of a flag.Value is usable. This commit fixes this.

This was raised in https://groups.google.com/g/golang-nuts/c/Atlr8uAjn6U/m/iId17Td5BQAJ.

cl/517349579 (google-internal)

cl/517387773 (google-internal)

This was raised in https://groups.google.com/g/golang-nuts/c/o85vycfiGVY/m/MblpnfF6BQAJ.

Before the 1.1.0 release it was possible to set os.Stderr to a different *os.File (like an os.Pipe) to capture output that is written to stderr. Restore that behavior.

This was reported in
https://groups.google.com/g/golang-nuts/c/Fh9o3CPjIIw/m/TyiUDY2uAAAJ.

We export this new API to make the internal and external versions
identical.

The context is currently plumbed through to the internal/logsink
package, but effectively discarded there.

cl/560684897 (google-internal)
cl/579771826 (google-internal)

Some environments are slow when syncing and holding the lock might cause contention.

cl/621846576 (google-internal)

Use the current process token to look up the user's name on Windows.

This is more reliable than using the USER or USERNAME environment variables, which are not always set, or might be overridden by the user accidentally or
maliciously.

It follows the implementation of the user.Current() implementation in the
standard library.

cl/650142356 (google-internal)

Windows Services are [spawned without `stdout` and `stderr`](https://learn.microsoft.com/en-us/windows/console/getstdhandle#return-value:~:text=If%20an%20application%20does%20not%20have%20associated%20standard%20handles%2C%20such%20as%20a%20service%20running%20on%20an%20interactive%20desktop%2C%20and%20has%20not%20redirected%20them%2C%20the%20return%20value%20is%20NULL.), so any attempt to use them equates to referencing an invalid file `Handle`. `stderrSink` returns the error, which makes `logsink` trigger the termination of the process. The result is that any call to `log.Error` (or `log.Fatal`) from a Windows Service will always crash the program.

This approach checks that `os.Stderr`'s embedded file descriptor (`Handle`, for Windows) is non-NULL once during `init` to determine its validity and if it fails, then never registers `stderrSink` as a logsink.

Disabling based upon whether `os.Stderr` is NULL was chosen because it's precise, doesn't actually influence the result of any output and doesn't require any syscalls, but still detects the case in which `stderr` is unavailable on Windows.

A rejected approach here would've been to swallow the errors from `stderrSink.Emit`, thus sparing us program termination at the hands of `logsink`. I rejected this approach because it felt like it could result in some subtle behavioral changes. For example, invoking `log.Error` after `os.Stderr.Close()` would no longer exit the program and that felt like a non-trivial change (although I can think of no reason why one would desire this behavior).

cl/680817112 (google-internal)

cl/648345242 (google-internal)

… second

If you do, then you truncate the existing file. So logging too much too quickly would lose log data.

cl/709080575 (google-internal)

This prevents an attack like the one described
[here](https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File#:~:text=On%20Unix%20based,with%20elevated%20permissions.).
An unprivileged attacker could use symlinks to trick a privileged
logging process to follow a symlink from the log dir and write logs over
an arbitrary file.

The components of the log names are program, host, username, tag, date,
time and PID. These are all predictable. It's not at all unusual for the
logdir to be writable by unprivileged users, and one of the fallback
directories (/tmp) traditionally has broad write privs with the sticky
bit set on Unix systems.

As a concrete example, let's say I've got a glog-enabled binary running
as a root cronjob. I can gauge when that cron job will run and then use
a bash script to spray the log dir with glog-looking symlinks to
`/etc/shadow` with predicted times and PIDs. When the cronjob runs, the
`os.Create` call will follow the symlink, truncate `/etc/shadow` and
then fill it with logs.

This change defeats that by setting `O_EXCL`, which will cause the open
call to fail if the file already exists.

Fixes CVE-2024-45339

cl/712795111 (google-internal)