On 32-bit glibc, define _TIME_BITS to 64 if not already defined

• On 32-bit glibc, define _TIME_BITS to 64 if not already defined

  On older 32-bit architectures such as i386, this redefines time_t to be 64-bit, and correspondingly increases the size of all system data structures that contain a time_t, such as struct timeval and struct stat. This is necessary to allow timestamps beyond January 2038 to be represented; as well as things that obviously deal with timestamps, this affects functions like stat() (and therefore our wrapper _dbus_stat()), which will fail with EOVERFLOW if asked to inspect a file whose correct timestamp does not fit in time_t.

  In particular, if the modification or access timestamp on /etc/machine-id has somehow been set to a post-2038 time, libdbus will consider the inability to stat() that file to be an installation error, and when using the deprecated dbus_get_local_machine_id(), that can cause third-party i386 software such as the Steam client to crash. Using 64-bit timestamps avoids that failure mode.

  Using 64-bit timestamps in glibc is an opt-in and not the default, because if done carelessly it can change libraries' ABIs. However, libdbus is careful not to include system headers and system data types in its own headers, with the only exceptions being extremely basic ISO C headers like <stddef.h> and <stdarg.h>; so we can safely do this without it breaking our ABI. This is similar to the reasoning for why commit 96ffc2a0 "configure.ac: support large-file for stat64" was a safe change.

  This change only affects glibc. Some non-GNU operating system libraries (such as musl) are less concerned with binary backwards compatibility than glibc, and therefore have incompatibly changed their ABI on 32-bit platforms to switch to 64-bit timestamps throughout; no action is needed on those platforms. If other non-GNU OS libraries have taken a route similar to GNU's, then maintainers of those operating systems are welcome to send tested merge requests similar to this one.

  An extra subtlety here is that _TIME_BITS=64 requires _FILE_OFFSET_BITS=64. In the Meson build, Meson unconditionally enables _FILE_OFFSET_BITS=64 where appropriate, and in the Autotools build, we already had that via AC_SYS_LARGEFILE, but in the CMake build we did not necessarily have this; so we also define _FILE_OFFSET_BITS=64 there if necessary, as a continuation of commit 96ffc2a0 "configure.ac: support large-file for stat64".

  On newer 32-bit architectures like x32, time_t is always 64-bit and so this has no practical effect.

  On 64-bit, setting these would have no practical effect, but to minimize risk I'm only doing this for 32-bit architectures.

  Resolves: #465 (closed)