[ ttc ] Compare modification time with nanosecond precision

[AlgebraicWolf]

Description

This PR changes TTC modification time comparison to use nanosecond-precision timestamps. It addresses the issue described in #3042, but, unlike the original PR, it does not break safety guarantees and does not risk missed rebuilds of source files. Since getting high-precision timestamps is platform-dependent and might not be supported everywhere, it reverts to current behaviour whenever there is no proper way to get nanosecond part of file's mtime.

This PR depends on #3044 to pass CI and avoid bootstrapping the compiler when upgrading.

[gallais]

Can you please edit the comment to document what these Ints are?
Better yet: why not introduce a record type with meaningful field names?

[AlgebraicWolf]

That sounds reasonable, I'll add a record for timestamps.
I guess another improvement I should make is adding a function that would get both seconds and nanoseconds of a timestamp and return a structure from C that would be turned into the newly introduced record. This would allow us to get both parts of timestamp in a single system call and potentially prevent a dangerous situation where time is modified between two system calls.

[AlgebraicWolf]

I've introduced a record as requested. Additionally, I've revisited the low-level interface to add capability to get both parts of timestamp and all time attributes of a file in a single syscall. This should eliminate the possibility of races when checking file's time. It looks like currently this PR ticks off two points in #2207.

I have also discovered that the current implementation of prim__fileModifiedTime on node backend is buggy -- even though the return type is Int, its result may turn out to be a floating point number at runtime. This has been fixed as well.