Fix audio resampling logic

[sakertooth]

After the SampleBuffer refactor in #6610, AudioResampler was introduced, and the sample playback logic was refactored as well (now within Sample::play). This left a couple of issues:

1. The sample playback functionality in Sample::play was not safe to call in real-time since it needed to make an allocation up front to store a temporary buffer of the necessary size.
2. The resampling logic in AudioResampler was not correct in a sense that it would not properly resample the signal. On each callback, AudioResampler would process the chunk of input samples as is, but it not take into consideration the previous input samples that it didn't get a chance to resample in the previous iteration. I believe this was the reason for the artifacts if buffer margins weren't used, but buffer margins were not the correct way to fix this. I also think they caused problems with the audio quality in Sample::play, in particular near the high frequencies (just from my own observations).

I addressed these two issues here. This is my second take at doing something like this after #7361, which was a nightmare on Windows builds, so any testing will be greatly appreciated. Note that unlike in there, I am not using the callback API, but still the full API in AudioResampler, just in a different way. AudioResampler allows callers to specify a callback to write into a very small SampleFrame buffer, which it will then be fed into libsamplerate over time. The libsamplerate state in AudioResampler is now correctly persisted across calls.

TODO

• After this PR, we may want to allow the user to specify the live interpolation quality in the audio settings. For now, sample playback always uses SRC_LINEAR (linear interpolation).
• In this PR, I might make sure we are using AudioResampler where libsamplerate is used directly if we aren't doing so already.