Fixing issue #845: inconsistent behavior in chained `--set` when one of them fails

[juergenRe]

This PR will do a settings change to the radio only when all of the chained --set commands are valid (parameter exists and value is accepted). If one of them fails, the whole command will be rejected and no changes are propagated to the radio.

During testing 2 additional problems have been fixed:

1. The receive thread runs "open loop" if there is nothing to receive. This will heavily block the main thread. I added a time.sleep(0.001) which will not delay the thread but can initiate a switch to the main thread if necessary. Reactivity of the programm was clearly increased due to this change. Remark: Today, one would use async def instead of a thread.

2. The local node will be instantiated when the meshinterface is created. However, the noproto attribute will not be passed to it. This blocks the execution in the unit tests for some cases. I added the initialization of the noproto during the creation of the local node field. Note: this implementation seems not properly thought. I don't see a need that the node knows how to transfer data. Shouldn't we rethink this?

Unit tests pass to 100%, as well as intergration tests. Smoke test not done, because 50% do not pass anyway (PR pending)