ThresholdWidget.reset() SIGNAL/SLOTS issue.

[king]

When working towards a fix for ticket:257, I added a reset() function to the ThresholdWidget, with the hope of avoiding emiting a changedValue, but this fails because the ThresholdWidget.setRange(min,max) code which is called by reset, ends up calling the basepair_spinner->setRange(min,max) function, which triggers a valueChanged emit, because by default the basepair_spinner's value is 0, and therefor gets bummed up to the new minimum. This then calls ThresholdWidget.setBasePairThreshold(min), which causes the analysis to be set to the minimum instead of the soft threshold, therefore triggering an nway analysis. Then the soft threshold gets set to the correct soft threshold triggering another loop and and another nway. The fix for ticket:257, fixes the problem by disconnecting the MussaWindow from the ThresholdWidget while the ThresholdWidget is being updated and then reconnects afterwards.

There is probably a way of having the ThresholdWidget break it's signals/slots at the correct times to get it to function properly without triggering an emit which ends up being sent back to the MussaWindow. For now, the fix to ticket:257 breaks the SIGNAL/SLOT loop (in MussaWindow.setAnalysis), just not in the ideal spot (ThresholdWidget).