Fix TZ issue in gettimeofday under Windows

Fix issue 6671 that I reported in the official (still?) bug tracker. My comment about it:

When running some experiments with timing functions on Windows, I ran into a problem that occurred only in Cygwin's Bash: gettimeofday provided non-UTC timestamps. After some code inspection, here and there, I found the culprit: the TZ environment variable affects gettimeofday and it shouldn't.

Unix.gettimeofday under Windows (mingw and msvc) uses C's `mktime` to convert a Windows-specific local time (provided by `GetLocalTime`) to a Unix timestamp. However `mktime` (here Microsoft's one in msvcrt) is sensible to the TZ environment variable. All would be well if `GetLocalTime` would also take TZ into account. But obviously it does not. Consequently, a wrong time offset appears if TZ is set and is not the current local time zone of Windows.

Why does it appears inside a Cygwin shell? TZ as some legitimate uses in Cygwin. And Cygwin defines by default TZ to the current time zone of the system (Europe/Paris for me). In this particular case, it should be good, no? obviously not! Microsoft and Cygwin do not have the same understanding of what is a good TZ value.

Regards
Mickaël
`GetSystemTimeAsFileTime` is used internally by `GetLocalTime` ... they both have approximately the same cost,. Although `GetSystemTimeAsFileTime` is expressed in hundreds in nanoseconds, it is not more so accurate (~15ms from what I've read). In fact, Windows 8 introduces `GetSystemTimePreciseAsFileTime` for this purpose.

However from what I have read on MSDN, `GetTickCount` seems not to be so precise either. But I did not run benchmark on it, and consequently, I did not work on this part.