Parallelize SF3 loading

[derselbst]

Loading SF3 files require decoding individual samples. Decoding is CPU-expensive and could make use of multiple cores. This PR distributes the decoding across multiple threads by using OpenMP tasks. This resolves #710.

The problem here is that the SF3 file is (usually) accessed via a common FILE*. Multiple threads seeking and reading around in the file would cause a race condition. Opening the FILE* multiple times is not an option either, as this is implementation-defined behavior. And since most implementations do not document this case, it becomes undefined behavior.

Originally, Marcus and I thought that using a memory-mapped file would be the solution to this. When I started implementing this I realized that this would create a "parallel-world" to the existing sfloader-callback mechanism. Secondly, it cannot be used if a user has set up custom callbacks via fluid_sfloader_set_callbacks(). Thirdly, memory-mapping is not supported for every file. If mmapping fails, we would still need to fall back to FILE*.

In this PR, I've chosen to synchronize the calls to fread() instead:

lock(mutex);
callback->fseek(); // seek to sample-offset
callback->fread(); // read into libsndfile buffer
unlock(mutex);

The fseek before the fread is required to ensure the sample is being read from the correct position.

Loading three SF3 file on my machine now takes only 4.5 seconds, rather than 13 seconds single-threaded before.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication