build: make GIO backend be enabled by default (bgo#686584)

Other IO backends were deprecated some time ago, so now the only option
is Gio. Before this happened, the backend to build was guessed at config
time by our M4 macros.

Problem is, if dependencies for GIO were not met, the default was to
silently not build any IO backend, which makes Banshee lacks lots of
useful features.

This commit changes this so it is now mandatory to pass the --disable-gio
flag if the user wishes to compile without any IO backend.

It doesn't completely solve bgo#686584 but helps alleviate the problem.
And has the added benefit of making more versions of dependencies be
clearly visible at the top of the macro.
build: Make gio-hardware be enabled by default (bgo#686584)

Before this change, at config time this M4 would determine if the GIO
Hardware backend (now the default and unique hardware backend) would be
built depending on the package dependencies present in the system.

Problem is, if dependencies for it were not met, the default was to
silently avoid building the backend.

This commit changes this so it is now mandatory to pass the flag
--disable-gio-hardware if the user wishes to compile without it.

It doesn't completely solve bgo#686584 but helps alleviate the problem.
And has the added benefit of making more versions of dependencies be
clearly visible at the top of the macro.
build: use the gui-thread-check profiler module by default when debugging

Upcoming versions of gtk# (2.99.1 and higher) will bundle this useful
profiler module by default. To reduce the feedback loop between developers
and bug reporters, banshee will run it whenever launched with the --debug
flag or when running in uninstalled mode (via "make run").

This way the logs that we get will include any traces of GUI calls that
were incorrectly not sent to the main thread, which in occassions can cause
crashes or unexpected behaviour.

Even though this is not bundled in gtk# 2.x series, it may still useful to
try to run it at launch, in case the user has installed the profiler module
on his own, or advised by devs: https://github.com/slluis/gui-thread-check

Signed-off-by: Alexander Kojevnikov <alexander@kojevnikov.com>
DapService: don't dispose the DAP source in the main thread (bgo#725870)

When testing the fix for bgo#723040, which was committed in [1],
I noticed that some GUI calls were not placed in the main thread
(thanks to the gui-thread-check profiler module), so I decided to
move them properly inside the delegate used in
ThreadAssist.ProxyToMain).

Unfortunately, this has apparently caused a regression (bgo#725870)
because Dispose() can be overriden to execute some sync operation
to the device (which shouldn't be in the main thread), in this
case MtpSource.SyncPlaylists() being called by DapSource.Flush(),
which could cause a deadlock.

We can put this call back outside the main thread. I've tested this
again with gui-thread-check and there are no wrong calls (possibly
because they were fixed in a better way in [2]).

[1] https://git.gnome.org/browse/banshee/commit/?id=b0e172f01374f807bf396b6a289e51f56f851e31
[2] https://git.gnome.org/browse/banshee/commit/?id=bfb3b817ca26d34370b09fff44fbc2d681d4c323