v1.13.3

Prevent multiple audio streams from starting over the top of each other when streamAudio commands are sent in rapid succession.
Reduce occurrences of spurious streaming warnings.
Send streamID with ufCancel message.
Add placeholder to only send ufCancel and audio/stop messages over BLE if a stream is stopped before completion.
Don't send ufCancel or audio/stop message when restarting a sound - rely on the ufStart command to restart the stream

The expected behaviour is that the previous sound will stop and the most recently clicked sound will play. Where a user puts the start sound block in a tight loop we should avoid spamming the BLE connection

Since the streamHandler is asynchronous and recursive with a queue, there are a few edge cases to beware of, and it has previously been possible to end up with two instances of sendStreamContents running simultaneously using the same streamID but different stream positions, creating interference. The code could potentially be refactored to simplify these aspects

We also need to ensure that if the ufCancel and audio/stop commands are sent, we wait for them to complete before attempting to start the next stream.

There is still potentially an edge case here where a new sound is started at the exact point between when sendStreamContents completes, but before sendStreamEndMsg does - in this case the isCancelled flag may be set but without a pending operation to clear it. This hasn't yet occurred in testing, but the issue should still be fixed