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
What is the cost of this system call? Shouldn't we also remove the `tickcount` hack?