Add a cache for samples

[sakertooth]

Adds an in-memory cache for samples. Callers can fetch data from the cache using two overloads: one for audio files, and another for Base64 strings. The cache stores weak pointers to the samples and returns shared pointers to the callers. However, the cache in the future will probably need to store the weak pointers along with sample thumbnails and possibly other kinds of metadata for each sample, which should be fairly easy to do as all that needs to be done is to store a collection of the data we need in a struct/class instead of just the weak pointer to the buffer.

For audio files, we check the last write time for the file to see if it needs updating each time it is fetched, and update it if necessary. For Base64 strings, we just compare the contents.

SampleLoader loads audio data by querying the cache for it, rather than creating them manually. As such, the SampleLoader::create* functions where renamed to SampleLoader::load*.

The memory usage has dropped significantly when using duplicate samples (htop readings went from 28.5% to 3.6% for me with a project that had a number of sample clips, each ~3 minutes long), and projects load faster (There is still some delay because of the waveform drawing, but this should be addressed soon. The speedup is more noticeable when you zoom all the way out before loading a project as a result).

Should supersede #7058 I believe.

[messmerd]

Gave it a quick look-over.

Also,

• Sample's move constructor and move assignment operator should be marked noexcept
• Sample::s_interpolationMargins should be renamed to Sample::InterpolationMargins since it is public
• sample_rate_t could be used instead of int for the sample rate (See this commit for what needed to be changed: 10162ec)

[sakertooth]

Sample's move constructor and move assignment operator should be marked noexcept
Sample::s_interpolationMargins should be renamed to Sample::InterpolationMargins since it is public
sample_rate_t could be used instead of int for the sample rate (See this commit for what needed to be changed: 10162ec)

Thanks, I will make another PR to address these issues separately. However, about the int -> sample_rate_t change, I never really understood why we have those types when basic types like int will work just as well. We already have to convert the sample rate to an int when processing the project file anyways. I can't really see the benefit using sample_rate_t brings, and it adds more complexity than int does (not in terms how long the type is.. well maybe, but more so having to know what is the actual type is that we are dealing with here on top of adding more code that we don't really need in the codebase).