Fix a bug in brush speed calculation algorithm

KisSpeedSmoother used a rather naive implementation of the filtering
for the tablet event rate estimation. It just dropped the samples which
were too different from the current mean. It resulted in a weird bug:
when a lot of the tablet events were postponed by the blocked GUI-thread
(e.g. during image creation) the mean value fell into the cave of very
small values and couldn't be pulled out of it.

The patch implements a more clever approach using KisFilteredRollingMean
class. It keeps all the incoming values, but strips off the most extreme
values when calculating the mean.

The new algorithm is rather computation intensive, so we could think
about some lazy-computation solution for the future. But currently,
the whole computation takes about 7 microseconds, which is about 0.1%
of the GUI-thread's time for hight quality Wacom tablets.

BUG:453401