gmain.c: Fix comment about Y2038 safety of g_get_real_time()

This comment was correct until commit adf1f98f62, when the `GTimeVal`
which the result was put into (introducing the Y2038-unsafety) was
dropped.

The adjustment and scaling of the `FILETIME` should not make it
Y2038-unsafe: the maximum `FILETIME` is 2^64-1. Subtracting the epoch
adjustment and dividing by 10 gives the timestamp 1833029933770955161,
which is in June 58086408216 (at just after 3am UTC). I think that’s
enough time to be going on with.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1438

glib/gmain.c

@@ -2686,7 +2686,7 @@ g_get_real_time (void)
   memmove (&time64, &ft, sizeof (FILETIME));
 
   /* Convert from 100s of nanoseconds since 1601-01-01
-   * to Unix epoch. Yes, this is Y2038 unsafe.
+   * to Unix epoch. This is Y2038 safe.
    */
   time64 -= G_GINT64_CONSTANT (116444736000000000);
   time64 /= 10;