...so it could happen that both the main thread at

> internal_bus_get
> dbus_bus_get_private
> avahi_dbus_bus_get
> avahi_client_new
> sd::AvahiNetworkService::setup
> sd::DiscoveryService::DiscoveryService
> sd::DiscoveryService::setup
> SdDLL::RegisterRemotes
[...]

as well as the thread

> internal_bus_get
> dbus_bus_get
> dbusConnectToNameOnBus
> sd::BluetoothServer::run
> threadFunc
> osl_thread_start_Impl
> start_thread

spawned from the main thread at

> sd::BluetoothServer::setup
> sd::RemoteServer::setup
> SdDLL::RegisterRemotes
[...]

are in D-Bus's internal_bus_get simultaneously (with disastrous consequences,
like SEGV) despite the _DBUS_LOCK(bus) there, unless you previously called
dbus_threads_init_default.  (Which the D-Bus documentation makes you believe can
be called from multiple threads, though a look at the implemenation makes it
clear that it really should be called from the main thread before any other
threads are created---which we still don't do; oh my.)

Other places that (indirectly) use D-Bus (tubes/source/file-transfer-helper.c,
vcl/generic/fontmanager/fontconfig.cxx, vcl/unx/gtk/window/gtksalframe.cxx might
need this, too.

Change-Id: I912829c615b46b05a89c07bd044b04f1e5f5e7ba