Fix sample decimation bug on audiodelays.Echo when freq_shift=True

[relic-se]

I've discovered that the frequency-shifting echo algorithm has a functionality bug in regards to how it fills the echo buffer during playback.

Currently, it pulls a sample from the echo buffer, calculates the decay, mixes in the input sample, and then iterates over the buffer from its current position to its next position (using the delay rate with bit shifting). If delay_ms is shorter than max_delay_ms, this loop may iterate over 2+ elements of the buffer. If there is data already in the echo buffer (when decay>0), it will make each element equivalent and lose the remaining echo data after the first element.

The following example demonstrates this problem and the audible effect on the output: https://gist.github.com/relic-se/f125dc56574d895f30eee52ec611e16f.

A before and after audio demonstration of the above example can be found here: https://drive.google.com/file/d/14L_8cUwpy_833RL01Nu4C3MQVEwN3zMq/view?usp=drive_link.

The fix for this problem requires that the echo decay and mix calculations be performed for each element of the buffer regardless of rate. With this update, the input sample will still be added at a faster rate, but all echo samples will be retained.

The downside of this fix is that if max_delay_ms is a large value and delay_ms is much smaller, the fast rate will require that many elements in the buffer will be iterated over, each requiring calculation. Since this module is limited to the boards featuring the RP2350, I don't think the performance impact will be too great.

[gamblor21]

Makes sense and looks good to me.