Add support for detecting progress stalls

[damageboy]

Yaap support a state called Stalled and provides the proper visual for a stalled progress bar.

What Yaap currently doesn't have, and to be quite honest, I have no clear vision of how to implement in a fool proof way, is automagical progress stall detection.

In the best case, there would be no additional setting required, except enabling stall detection, and Yaap would be able to detect stalls when the rate drops to 0.

The devil is in the details though:

• How to detect stalls without erroneously detecting very slowly updating progressbars as stalled?
• How much progress should be made before stall detection can begin?

[jamesbeegle]

Thinking on this, I think it's okay to show a stall if a particular item is running exceptionally slowly and that is expected by the user - they should understand the expected performance of their software and the items it is processing, and should understand that a progress bar library may not understand every subtle detail.

As such, I think a good approach to this would be to start with the stalled visual indicator until the first iteration completes and provides a datapoint for likely cycle times for the following items. From there on, 'stalled' means an iteration that is taking more than the usual time (the median, or maybe average of all data points excluding the top and bottom 10%) times some variance budget. That budget number might work well as a static value like 5, or you may want to determine it with some formula that increases it as the consistency of the cycle times goes down.

Another approach might be to periodically sort the cycle times and just get the 95th percentile time and use that times 1.2 (numbers based on gut feeling).

Or convert the data to a histogram and select a threshold that covers 98% of the current values.

IMO, any of these approaches would cover what I expect from a progress bar - it's not exactly a space filled with shining examples of quality.