fix: timestamp resolution to microseconds on Windows

[ShawnCZek]

The timestamp resolution was changed to microseconds in https://github.com/getsentry/sentry-native/pull/995. However, this has never correctly worked on Windows because SYSTEMTIME, a return value from the underlying call to GetSystemTime(), contains only milliseconds, not microseconds: https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-systemtime.

Instead, GetSystemTimeAsFileTime() can be used as its return value "contains a 64-bit value representing the number of 100-nanosecond intervals". This also helps in reducing two API calls to just one.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 83.78%. Comparing base (4c47d97) to head (dda6e61). Report is 1 commits behind head on master.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #1039 +/- ## ========================================== + Coverage 83.76% 83.78% +0.01% ========================================== Files 53 53 Lines 5512 5512 Branches 1198 1198 ========================================== + Hits 4617 4618 +1 Misses 781 781 + Partials 114 113 -1 ```

[ShawnCZek]

Actually, on Windows 8 and later, GetSystemTimePreciseAsFileTime() is available, which is even more precise and is encouraged to be used by Microsoft: https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps#guidance-for-acquiring-time-stamps

[dacap]

This PR made any binary linked to sentry-native depends on GetSystemTimePreciseAsFileTime()/incompatible with Windows 7 by default (https://github.com/aseprite/aseprite/issues/4691).

I know that probably we should not be compiling with _WIN32_WINNT >= 0x0602 to give support for Windows 7 (which is 0x0601), but actually we're compiling with _WIN32_WINNT=0x0A00 just to use Windows 10 APIs dynamically (known the API structures) and load functions dynamically.

Probably an approach like Microsoft's STL should be used for this:

https://github.com/microsoft/STL/blob/faccf0084ed9b8b58df103358174537233b178c7/stl/src/winapisupp.cpp#L161-L170

Where GetSystemTimePreciseAsFileTime is loaded dynamically if _STL_WIN32_WINNT < _WIN32_WINNT_WIN8 (do we need a SENTRY_WIN32_WINNT?).

At the moment we'll revert this change to continue giving support for Windows 7.

[ShawnCZek]

I guess we would have to do something similar to the following:

https://github.com/getsentry/sentry-native/blob/65bfb62e2f424d2b8cf35c5d8c5efdc88f92c2aa/src/sentry_sync.c#L38-L45

However, what is the stand on supporting operating systems that went EOL 4+ years ago, especially when done non-standardly by changing definitions? For instance, Sentry Native will not work properly for Windows XP using your technique because of instances like this (GetTickCount64 has only been available since Windows Vista):

https://github.com/getsentry/sentry-native/blob/65bfb62e2f424d2b8cf35c5d8c5efdc88f92c2aa/src/sentry_utils.h#L145-L152

Frankly, I am not a maintainer of this library; it is up to the Sentry team how they want to resolve this. But I do hope we are not defaulting to the previous solution as it is inefficient and inaccurate, as discussed here: https://devblogs.microsoft.com/oldnewthing/20131101-00/?p=2763.

Likewise, I wish new systems were not disadvantaged because of supporting old systems that <1% of users use; GetSystemTimePreciseAsFileTime() turned out to be extremely precise in our case.

[dacap]

We are still giving support for Windows Vista and 7 as we still have ~750 users on those platforms. Windows XP support was dropped and probably Vista and 7 will be dropped in a couple of years. But until we can keep working the code on those platforms that will be great.

The MSVC STL library is already doing this job of dynamically loading the function, probably we can just use __crtGetSystemTimePreciseAsFileTime() when compiling with MSVC.