We have various options for strerror(), with ups and downsides:

- strerror()

    - returns pointer that is overwritten on next call. It's convenient
      to use, but dangerous.

    - not thread-safe.

    - not guaranteed to be UTF-8.

- strerror_r()

    - takes input buffer and is less convenient to use. At least, we
      are in control of when the buffer gets overwritten.

    - there is a Posix/XSI and a glibc variant, making it sligthly
      inconvenient to used. This could be solved by a wrapper we implement.

    - thread-safe.

    - not guaranteed to be UTF-8.

- g_strerror()

    - convenient and safe to use. Also the buffer is never released for the
      remainder of the program.

    - passing untrusted error numbers to g_strerror() can result in a
      denial of service, as the internal buffer grows until out-of-memory.

    - thread-safe.

    - guaranteed to be UTF-8 (depending on locale).

Add our own wrapper nm_strerror_native(). It is:

    - convenient to use (returning a buffer that does not require
      management).

    - slightly dangerous as the buffer gets overwritten on the next call
      (like strerror()).

    - thread-safe.

    - guaranteed to be UTF-8 (depending on locale).

    - doesn't keep an unlimited cache of strings, unlike g_strerror().

You can't have it all. g_strerror() is leaking all generated error messages.
I think that is unacceptable, because it would mean we need to
keep track where our error numbers come from (and trust libraries we
use to only set a restricted set of known error numbers).