Closing a device doesn't terminate pending transfers

[www.google.com/accounts/o8/id?id=aitoawmz93igogrpknbehv21jdxrf37ft8ksncg]

Probably related to Ticket #82.

According to the Valgrind error below, it looks like libusb_close doesn't actually clean-up any pending transfers causing those transfers to potentially crash when they timeout/complete. At the very least, this condition should be warned about & prevented by aborting the close (assuming cleanup is a more difficult problem).

==1569== Invalid read of size 4
==1569==    at 0x5FBD6E7: cancel_control_transfer (linux_usbfs.c:1699)
==1569==    by 0x5FBD9BF: op_cancel_transfer (linux_usbfs.c:1767)
==1569==    by 0x5FB819C: libusb_cancel_transfer (io.c:1309)
==1569==    by 0x5FB891B: handle_timeout (io.c:1707)
==1569==    by 0x5FB8A94: handle_timeouts_locked (io.c:1760)
==1569==    by 0x5FB8B64: handle_timerfd_trigger (io.c:1788)
==1569==    by 0x5FB8E71: handle_events (io.c:1878)
==1569==    by 0x5FB907D: libusb_handle_events_timeout_check (io.c:1970)
==1569==    by 0x5FB9142: libusb_handle_events_timeout (io.c:2005)
==1569==    by 0x43E8DC: USBEventWatcher::usbActivity(int) (event_watcher.cpp:144)
==1569==    by 0x448B62: USBEventWatcher::qt_metacall(QMetaObject::Call, int, void**) (moc_event_watcher.cxx:80)
==1569==    by 0x5C96B26: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3280)
==1569==  Address 0xa759c48 is 72 bytes inside a block of size 76 free'd
==1569==    at 0x4C27D71: free (vg_replace_malloc.c:366)
==1569==    by 0x5FB5643: do_close (core.c:1023)
==1569==    by 0x5FB57AF: libusb_close (core.c:1080)
==1569==    by 0x446607: usb::DeviceHandlePtr::~DeviceHandlePtr() (devicetransport.h:30)

[www.google.com/accounts/o8/id?id=aitoawmz93igogrpknbehv21jdxrf37ft8ksncg]

Yup - just verified that I had been closing the device in the middle of the transfer. I now reference count the opens myself. Would it make sense to add that reference counting for libusb_device_handle as well?

[www.google.com/accounts/o8/id?id=aitoawkqduuilezm1tu1seo2uz1ndphzkn82lqc]

Even though this is incorrect usage of the API, the internal state is messing up. The underlying flaw I believe is a duplicate of #82