fix coredump in unit test

[Jun-T]

fs_init() must be called before early_init() in init/helpers.lua

If I run 'make unittest' on my Mac (macOS 10.14/Mojave or 12/Big Sur, intel CPU), every test produce a core dump. Does this happen only to me? I have no idea why it works in CI, but anyway this PR fixes the core dumps on my Macs.

Call sequence in the core is:
early_init() main.c:197
set_init_1() option.c:508
runtimepath_default() runtime.c:1205
get_lib_dir() runtime.c:1175
os_isdir() fs.c:137
os_getperm() fs.c:777
os_stat() fs.c:761
fs_loop_lock() fs.c:72
uv_mutex_lock(&fs_loop_mutex) thread.c:352
abort()

In .deps/build/src/libuv/src/unix/thread.c:

void uv_mutex_lock(uv_mutex_t* mutex) {
  if (pthread_mutex_lock(mutex))
    abort();	// line 352
}

So pthread_mutex_lock(&fs_loop_mutex) failed.
The reason seems to be simple. fs_init() was not called and fs_loop_mutex has not been initialized.
fs_init() was moved out from early_init() in main.c by commit b87867e, but unit/helpers.lua was not updated accordingly.
To cimport()'ing fs_init() to lua, I created a new file src/nvim/os/fs.h. Is there a better way?

Or we can modify main.c so that fs_init() is called by early_init(), but fs_init() need also be called before init_startuptime() so some tweak is necessary.

[justinmk]

Looks like a perfectly fine solution, thank you! The unit test setup is known to be a bit fragile; ideally it would just call one function shared with main.c but we may not need to bother unless we see more commit activity involving the startup sequence and/or unittests.