Dap: Prevent misleading exceptions in LoadFromDevice()

In some systems such as mine, when you connect a device, and after
that, you switch it from MTP mode to PTP mode, it could happen that
two events for the same device, one for mapping and the other for
unmapping, could arrive almost at the same time:

[19 Debug 23:43:39.175] Found DAP support (Banshee.Dap.Mtp.MtpSource) for device Nexus 4 and Uuid /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2
[20 Debug 23:43:39.175] Unmapping DAP source (/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2)

The Unmap one was causing a call to DapSource.Dispose() which, in
this case it set MtpSource.mtp_device to null, which would then
generate an ArgumentNullException when trying to enter into a
lock(), because the LoadFromDevice() method was still in progress
(fired by the Map event).

These 2 events coming together is very inconvinient because the
load process (LoadDeviceContents()) is threaded, so if we need
that the Unmap event interrupts the load process of the Map event,
an exception will definitely happen. However, it's better that
this exception is comprehensible instead of misleading, and for
that we're going to use Thread.Abort() API which will generate
a ThreadAbortException, rather than an ArgumentNullException or
other even more misleading...
DapSource: remove unneeded overriden properties

They were simply calling to their base counterparts so it is
safe to remove them.
DapService: avoid freezing Banshee when unmapping device (bgo#723040)

It could happen that a Map event generated a process that
could take a while to detect the device, which would hold the
DapService.sync lock, which is also used by the Unmap events,
and the latter events run in the main thread, so this could
mean that banshee gets frozen for a time as long as it takes
to detect/connect to the device.

To fix this we simply need to spawn a thread for the Unmap
operation. This thread will later call ThreadAssist API again
to come back to the main thread when the UI needs to be
changed, but that's ok. On top of that, the Dispose() was
actually being called outside this ThreadAssist.ProxyToMain()
call, so it was generating bad gui-thread-check traces, so
it's a good time to fix this as well.