Runtime: Increasing the Granularity of SetLastAccessTime and SetLastWriteTime to 100 nanoseconds i.e number of ticks

[Anipik]

```C#
[Fact]
public void SetNanoSeconds()
{
string firstFile = GetTestFilePath();
File.WriteAllText(firstFile, "");

var t = DateTime.UtcNow;
File.SetLastWriteTimeUtc(firstFile, t);
long firstFileTicks = File.GetLastWriteTimeUtc(firstFile).Ticks;
long secondFileTicks = t.Ticks;

 Console.WriteLine(firstFileTicks);
 Console.WriteLine(secondFileTicks);
  //Assert.True(t == File.GetLastWriteTimeUtc(firstFile));
  Assert.True(firstFileTicks == secondFileTicks, $"First File Ticks\t{firstFileTicks}\nSecond File Ticks\t{secondFileTicks}");

}

Both the asserts fail here

636717138509940000
636717138509946880
System.IO.Tests.File_GetSetTimes.SetNanoSeconds [FAIL]
First File Ticks 636717138509940000
Second File Ticks 636717138509946880
```

This is due to the fact that while setter we use DataTimeOffset.ToUnixTimeMilliseconds() function to get the ticks, which drops the last few bits.

We can define a new public api called DateTimeOffset.ToUnixTimeNanoseconds() in DateTimeOffset class. We have some of the constants setup here https://github.com/dotnet/coreclr/blob/master/src/System.Private.CoreLib/shared/System/DateTimeOffset.cs#L40 to get the correct values

cc @danmosemsft @tarekgh @JeremyKuhne

[jkotas]

DataTimeOffset.ToUnixTimeMilliseconds()

What would the signature of this method be to avoid high bits being dropped?

We do not need a new public API on DataTimeOffset to fix this. System.IO.FileSystem can do the conversion locally without a public API.

[tarekgh]

I agree with @jkotas that System.IO can just do the right calculations without any need for a new API.

[Anipik]

okay sure. @tarekgh just for curiosity, is there any reason we only have public api only for seconds and milliseconds ?

[tarekgh]

@Anipik we already have the issue https://github.com/dotnet/corefx/issues/24555 tracking that. look at the last comments on this issue to know why we didn't proceed yet with the proposed APIs.

[Anipik]

Thanks @tarekgh

[danmosemsft]

@Anipik presumably this means that MSBuild will still over build (copy unnecessarily) ? I thought previous changes had fixed that...

[Anipik]

@danmosemsft the previous changes were little bit different from this one. And this particular case occurs very few times. Most of the operations preserve the timestamps like copy, move. This case occurs when we deliberately use setLastWriteTime or setlastAccessTime properties.

[danmosemsft]

@Anipik OK, that's not urgent then.