Use capi for syscalls that break under musl's handling of 64-bit time_t

[redneb]

I maintain a repo with builds of GHC for the musl C standard library and I encountered a subtle bug of this library that affects GHC under 32-bit architectures with musl.

In 32-bit architectures, there was a transition where the C type time_t was redefined to be 64-bit in order to address the Y2038 problem. The way this was handled by musl was by introducing new versions of all affected syscalls that work with 64-bit time_t (e.g. utimensat_time64 is like utimensat but with 64-bit time_t). In addition, a redirect was introduced to create an alias of the new versions of these functions under the old name (e.g. here's the redirection for utimensat).

The problem is that this redirection is defined as a C macro in a C header file and as such, it does not get picked by GHC when the foreign function import is done via ccall, but works just fine when capi is used. So this PR changes utimensat to be imported with capi, which should be a fairly uncontroversial change.

[Rufflewind]

Merged via f6b288b