(fix) Waveform scratching: fix seeking to hotcue while scratching is enabled

[ronso0]

This is a first (still dirty) fix for #13981
TL;DR
No need to rush this into 2.6

Recently I compared the available methods for scratching with controllers, and while PositionScratchController (developed for waveform scratching) turned out to be the best (for me, no drift, smooth at low rates, nice spinback) I can't really use it as I want to due to #13981

This fixes the crazy seeking and allows seeking to a hotcue when the wheel is stopped or turned slowly.
It's good enough quickfix for me, and I can use PositionScratchController in my mapping for new year's eve.

Though this is just a first step to understand what's happeing with EngineBuffer, ReadAheadManager, RateControl and PositionScratchController. A real fix needs to be more robust, probably requiring some tweaks in EngineBuffer and other involved units.

[ronso0]

Until now this was a no-op in RateControl and with the fix it's causing trouble so I removed it.

[ronso0]

Still not working as desired. I'm a bit lost here since I don't fully understand how the filters work here:
Either seeking works mostly and loop-scratching works mostly, or seeking works perfectly and loop-scratching is broken sometimes (now I'm using the latter for my mapping since seeking is more importat to me).
Note that I've been testing this lately with a controller implementation, ie. scratch_position is set with my jog wheel position. (which works flawlessly btw)

So, I really don't get how to fix both as I'm not 100% sure loop-scratching works 100% in main.
Maybe the sampling intervals are not workign well for controller mapping which sends updates much faster that the audio engine @5ms latency, so maybe we can ditch the interval stuff and simply process at ever call from RateControl.
That said, it might make sense to sub-class / clone PositionScratchController for controller use.

Any help is appreciated!