sysdeps: Use C11 stdatomic.h where possible

• sysdeps: Move declarations used from C++ to their own header

  I want to use <stdatomic.h> in dbus-sysdeps.h, but if we do that, we won't be able to include that header into C++ code on all compilers. Move the declarations for new internal Windows-specific functions introduced in commit 17a23d08 "dbus_threads_init_default, dbus_threads_init: be safe to call at any time" into their own header.

• sysdeps: Use C11 stdatomic.h where possible

  On Unix, dbus has historically used gcc-specific lock-free atomic intrinsics where available, falling back to a pthreads mutex where possible. Meanwhile, on Windows, it has historically used InterlockedIncrement() and similar library functions (in practice wrappers around lock-free intrinsics on real Windows, but IPC calls into wineserver on Wine).

  ISO C11 provides a new header, stdatomic.h, with standardized support for atomic operations. Exactly how these are implemented is a compiler quality-of-implementation decision, but any reasonable compiler implementation on a modern CPU should be using intrinsics. Let's use this wherever possible, falling back to our old implementation only if the C11 implementation is unsupported.

  One concrete benefit that we get from this is that when compiling with mingw-w64 gcc and running via Wine, this makes atomic reference counting operations into a simple local operation, rather than IPC to wineserver which can be very slow. This should make our CI tests considerably more reliable.

  In all vaguely modern gcc versions (gcc 5.5 or later) and in contemporary versions of clang, the default compiler mode is C11 or later with GNU extensions. We intentionally do not ask for any specific C standard, so we can use C11 features like this one, as long as we do so conditionally.

  The Microsoft Visual C compiler does not currently support this without special options, so we still use the Interlocked family of functions when compiling for Windows with MSVC.