Render timing.c robust in the face of strangeness. The strangenesses

in question vary per OS: on Windows the problem is that WM_TIMER
sometimes goes off too early, so that GetTickCount() is right and
the callback time is wrong, whereas on Unix the problem is that my
GETTICKCOUNT implementation comes from the system clock which means
it can change suddenly and non-monotonically if the sysadmin is
messing about (meaning that the timing of callbacks from GTK or
select timeouts is _more_ likely to be right than GETTICKCOUNT).
This checkin provides band-aid workarounds for both problems, which
aren't pretty but ought to at least prevent catastrophic assertion
failure.

[originally from svn r5556]

unix/unix.h

@@ -47,6 +47,11 @@ unsigned long getticks(void);	       /* based on gettimeofday(2) */
 #define GETTICKCOUNT getticks
 #define TICKSPERSEC    1000	       /* we choose to use milliseconds */
 #define CURSORBLINK     450	       /* no standard way to set this */
+/* getticks() works using gettimeofday(), so it's vulnerable to system clock
+ * changes causing chaos. Therefore, we provide a compensation mechanism. */
+#define TIMING_SYNC
+#define TIMING_SYNC_ANOW
+extern long tickcount_offset;
 
 #define WCHAR wchar_t
 #define BYTE unsigned char