possible getopt stderr output changes

[Rich Felker <dalias@libc.org>]

The current getopt code uses some ugly write() sequences to generate
its output to stderr, and fails to support message translation. The
latter was an oversight when locale/translation support was added and
should absolutely be fixed. I'm not sure whether we should leave the
code using write() though or switch to fprintf.

The original motivation for write() was to avoid pulling in the printf
core and stdio in programs that use getopt but otherwise don't need
printf/stdio. However, the use of multiple write() calls splits the
messages up into multiple syscalls unnecessarily (increasing the
likelihood of getting output interleaved with other processes running
in parallel on the same stderr) and failure to use the stderr FILE
makes it so the output is not even atomic within the same process. I
don't think there's any formal requirement of atomicity here, but it
could be seen as a QoI issue.

Note that even converted to use fprintf, the code would still be
mildly ugly, since it would have to use multiple %s formats and locale
lookups to construct the message. This is because musl security policy
forbids use of translatable format strings in libc; instead,
translatable literals have to be used and processed by a fixed,
non-translated format string.

Thoughts on what color the bikeshed should be?

Rich