Improve SR542 task reliability

[abergerSRS]

I found some bugs in the SR542 task for the SR860. Tried to improve the reliability of the code but still have several sticking points and questions:

1. How are the "Default" values for input parameters established?

2. The values in the task input parameters are not read in at task startup and sent to the instruments. This only occurs when "Apply" is pressed. So if apply is not pressed, the values stored in self.params could be out-of-sync with the actual instrument configuration.

3. "Stop" needs to be able to force a task exit. This can be challenging with multi-threaded applications (i.e. the "Stop" won't be processed until the test returns). If there is a loop in the test code, you can end up waiting forever even though you've pressed "Stop". Perhaps something like this in srsgui/task/task.py:

   def delay(self, dt_s):
   if self._keep_running:
       time.sleep(dt_s):
   else:
       raise InterruptedError("Aborted.")

4. Unchecking "capture" boxes and re-capturing doesn't appear to update

5. I suggest an explanation of the "capture" window, e.g. a. Show methods [M] b. Show raw cmds

6. Not alerted by raise ValueError. Can this pop up a message? What is the right way to do so?

[srsrga]

1. Inputs in Task.input_parameters are built as widgets in InputPanel, when the user select a task from the application menu. The default values are displayed in the widgets initially.

2. A task cannot access directly to widgets in the GUI. When "Apply" button is pressed, the values in widgets are copied to inputs in Task.input_parameters, and the task can read values in inputs. If "Apply" button is pressed while a task is running, new values can be delivered to the running task. It is the only way a running task interact with GUI input panel. This limitation is imposed because the Task is completely uncoupled from GUI.

CommandInput is added to the module last, and it behaves differently from other inputs. When "Apply" button is pressed, the value from the command input goes to the instrumen, not to the command inputt. The task has to read the value directly from the instrument, not from the command input.

3. When the stop button is pressed, Task.is_running() becomes False. It is a responsibility of a task to call the method regularly, and stop when it is False.

5, 6. It was a bug in srsgui capture dock. The dock is still implementing. It will take for a while to complete.

7. Raising an exception with a proper message is the right way to abort the task. Unhandled exception will stop the task, and the super class Task class will handle the exeption and logging will display the message to the console.