Misc. enhancements (driven by RSPDuo support needs)

[vsonnier]

Hello @fventuri, @SDRplay. This is PR for CubicSDR destined to have better support for RSPDuo, but staying generic at the same time.

• Addition of Device name in the Title bar: this will allow to distinct between Master and Slave instance names in the Duo context.
• Better handling of "lost device" by checking SoapySDR readStream return code SOAPY_SDR_NOT_SUPPORTED, or catching exception on readStream and stopping the Cubic streaming thread cleanly.

Some notes on the second point :
Soapy API has a special code meaning SOAPY_SDR_NOT_SUPPORTED that should be returned by the readStream on the Slave instance when the Master get lost.

Although the Cubic code now also catch any exception around the readStream code to stop Cubic side cleanly, last time I checked (pre-Cx11 I confess) it is considered very bad practice to throw exceptions between threads, especially for a parfect valid case of "dying Master instance" like this.

Of course there is also less garantees that other clients of Soapy API are expecting exceptions to be managed at all in their particular application.

Either way even with those changes from the user perspective the Waterfall and Spectrum will simply stop animating in case of Duo Master loss on the Slave side. Not much more can be done without developping an insane amount of code compared to this small use case.

I've tested on RSP2 (old driver) with a testing piece of code either throwing a std:runtime_error or returning SOAPY_SDR_NOT_SUPPORTED after some time to simulate it: The WF/Spectrum stream animation stops, but I can still going to either Start/Stop deviceor Devices dialogs to restart it. So it is as clean as it can get I think.

[vsonnier]

Let this change go live