[std/times]getTime now uses high resolution API on windows

[ringabout]

Function	Return type	Resolution	Timezone
GetLocalTime	SYSTEM_TIME (1ms)	~10-15 ms	Local
GetSystemTime	SYSTEM_TIME (1ms)	~10-15 ms	UTC
GetSystemTimeAsFileTime	FILE_TIME (0.1us)	~10-15 ms	UTC
GetSystemTimePreciseAsFileTime	FILE_TIME (0.1us)	0.1 us	UTC
GetTickCount	Int32 (1ms)	~10-15 ms	n/a
GetTickCount64	Int64 (1ms)	~10-15 ms	n/a
QueryPerformanceCounter	Int64 (ticks)	0.1 us	n/a

see https://stackoverflow.com/questions/34557407/queryperformancecounter-or-getsystemtimepreciseasfiletime-when-using-sntp

getTime on Unix (except Macos) uses high resolution, so make it more consistent on windows. Eventually Macos should use high resolution API too.

[rockcavera]

The problem is how random.initRand() is initialized. The state is acquired through times.getTime(), which when requested in a short time, will always return the same value. I always thought this implementation was wrong. It would be okay to use monotimes.getMonoTime(), which always returns a different value.

About std/tempfiles, does the implementation really need to start a new rng state every time? I do not think so.

[timotheecour]

@xflywind see #18403 which had to revert getSystemTimePreciseAsFileTime because it's not supported in windows 7; we should find a clean way to detect this to enable it when available, ideas welcome (ideally ones that generalize to other similar cases)