Never use non-libdbus threading primitives

Never use non-libdbus threading primitives

This lets us simplify considerably, by assuming that we always have both
recursive and suitable-for-condition-variable mutexes.

The Windows implementation has been compiled (on 32-bit mingw-w64)
but not tested. Justification for the approach used on Windows,
and in particular, using the existing "non-recursive" locks as if
they were recursive:

* We've been using them in conjunction with condition variables all
  along, so they'd better be suitable

* On fd.o #36204, Ralf points out that mutexes created via CreateMutex
  are, in fact, recursive

* Havoc's admonitions about requiring "Java-style" recursive locking
  (waiting for a condition variable while holding a recursive lock
  requires releasing that lock n times) turn out not to apply to
  either of our uses of DBusCondVar in DBusConnection, because the
  lock is only held for a short time, without calling into user code;
  indeed, our Unix implementation isn't recursive anyway, so if
  the Windows implementation reaches the deadlocking situation
  somehow (waiting for condition variable while locked more than once),
  the Unix implementation would already have deadlocked on the same
  code path (trying to lock more than once)

One possible alternative to a CreateMutex mutex for use with condition
variables would be a CRITICAL_SECTION. I'm not going to implement this,
but Windows developers are welcome to do so.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=36204
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744
Reviewed-by: Thiago Macieira <thiago@kde.org>