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
I think the ~15ms resolution of `GetSystemTimeAsFileTime` is in fact the tick frequency, so the resolution will be the same whatever we do.

But my guess was that the `tickcount` hack was introduced to avoid paying the cost of translating the seconds into the SYSTEMTIME record (which `GetLocalTime` does in addition to the system call) and then back into a number of seconds (with `mktime`). Now that these translations are done, maybe we can get rid of the complexity and just do the system/library call every time. @xavierleroy should be able to tell us more about this.

Or someone should measure the overhead of `GetSystemTimeAsFileTime` compared to `tickcount`.