Some Nix wrappers are not signal-safe

[SteveLauC]

For those syscalls that are signal-safe, their Nix wrappers may not be.

For example, stat(2) is signal-safe, its Nix wrapper uses the NixPath trait, which will allocate if the passed argument has a length greater than MAX_STACK_ALLOCATION, and allocation is not signal-safe, making the wrapper signal-unsafe.

I kinda think we should take a look at those functions that are asked to be signal-safe by the standard, and check if the corresponding Nix wrappers are safe or not, if not, then we should document it so that our users can be aware.

[SteveLauC]

This should also be done in Nix 0.30.0 if I can make it.

[SteveLauC]

Tried this today, and I am not going to finish this because:

• Nix wrappers use std types, and we have no guarantee of signal safety there as this concept is for C, doesn't really apply to the Rust stuff.
• It might not be worth to do it as well. When using signal handlers, the only thing one might want to use is libc::write(2), like ctrlc and tokio does, as this is definitely safe. Trying other things that are in the white list may not be worthwhile.