libbladeRF: Workaround for deadlock condition

This is a workaround for issue (#324).

We appear to have a lock ordering issue with our stream->lock and the underlying
libusb event lock.  When a libusb event occurs, it acquires its event lock and
then our callback acquires a stream lock.  When we asynchronously submit a
transfer, we acquire the stream lock and then libusb acquires its event lock
under the hood. If a callback occurs while we're submitting a transfer on the
same stream, deadlock ensues, due to the above asymmetry in lock acquisition.

Ultimately, we'll need to review our locking scheme and libusb event handle to
address underlying design issues here, and potentially trim some fat.

For now, the lock is just dropped after all metadata has already been updated,
and reacquired after submission.
bladeRF-cli: Launch RX/TX tasks only when handling input

There's no point in starting these threads up if we're performing
operations from command line flags that will cause the program to
exit, rather than enter the main input loop, which may execute
the rx or tx commands.