Zero out the caller's FileInfo in all the functions which populate the
struct.  The contents are considered private, so we need to ensure
it's initialized.

If the stat call fails, the buffer we get back from libuv may not have
any valid data in it, so don't copy it into the caller's FileInfo.

This was happening, expectedly, in functional/ex_cmds/write_spec.lua's
"write errors out correctly", which caused it to fail in certain
environments:

    test/functional/ex_cmds/write_spec.lua:130: Expected objects to be the same.
    Passed in:
    (string) 'Vim(write):E212: Can't open file for writing: not a directory'
    Expected:
    (string) 'Vim(write):E166: Can't open linked file for writing'

fix #8075

Vim's documentation simply states that libcallnr() should be used "for a
function that returns an int".  Based on the tests, code, and common
syscall interfaces, this should likely be taken literally instead of
trying to apply some well-defined type lipstick.

Notably, this change fixes Test_libcall_libcallnr on hppa (a 32-bit
big-endian system).

Problem:  ":lang messages en_US.UTF-8" no longer overrides the language
          detected from the environment (at startup).
Solution: In os_setenv, special-case "LC_ALL", "LANG", et al. to use
          putenv_s instead of uv_os_setenv.

fixes #11045

Without this "sysinit uses VIM if XDG_CONFIG_DIRS unset" fails with an
existing `/etc/xdg/nvim/sysinit.vim` file, because `XDG_CONFIG_DIRS=` is
not considered, but the default ("/etc/xdg") used then.

Pulse every 0.1s only.

This makes `!yes` look much better (less busy).