Improve the doc for `utimensat(3)` and `futimens(3)`

[SteveLauC]

One advantage of utimensat(3) and futimens(3) over utimes(2) is that they can just set one timestamp at a time.

Cite the man page:

If the tv_nsec field of a timespec structure has the special value UTIME_NOW, the file's relevant timestamp shall be set to the greatest value supported by the file system that is not greater than the current time. If the tv_nsec field has the special value UTIME_OMIT, the file's relevant timestamp shall not be changed. In either case, the tv_sec field shall be ignored.

Say I wanna update atime and leave mtime unchanged, if using utimes(2), I have to retrieve the previous mtime using stat(2) or something similar, but using utimensat(3) or futimens(3), I can just easily set the tv_nsec field of that timestamp to UTIME_OMIT.

So I think this feature deserves to be documented.

[rtzoeller]

It seems like there are two reasonable options:

1. Make atime and mtime type Option<&TimeSpec>, and set UTIME_OMIT internally.
2. Re-export UTIME_OMIT from the nix crate, and document it better.

Option 1 seem Rustier, but Option 2 avoids breaking API compatibility with the existing function. @asomers @SteveLauC @sargun thoughts?

[SteveLauC]

Option 1 is a more natural way. But to avoid making existing user programs broken, what about adopting option 2 in the interim, leaving a TODO in it, and changing to option 1 when we can introduce breaking APIs