Prefer native WAV decoding before SDL_sound

[Tutez64]

Summary

Prefer Lime's native WAV decoder before SDL_sound when eagerly loading audio buffers from files or bytes.

Rationale

Some PCM WAV sound effects decoded through SDL_sound first can produce audible startup artifacts when loaded via AudioBuffer.fromBytes(). The same assets decode and play correctly when Lime's native WAV::Decode() path is used first.

For plain PCM WAV files, the native decoder is the more direct path: it reads the RIFF/WAVE chunks and copies the sample data without routing through SDL_sound conversion. SDL_sound remains available as a fallback for formats or WAV variants that the native decoder does not support.

Repro

LimeWavSdlSoundArtifactRepro.zip

[dimensionscape]

Would prefer to find out what is causing the audio noise rather than papering over the problem.

[Tutez64]

I agree that the SDL_sound artifact should be investigated.

The reason I still think this change is reasonable is that this is also a decoder-priority issue. For eager decoding of RIFF/WAVE PCM data, Lime already has a native WAV decoder that handles the simple PCM case directly. Using that first keeps the common uncompressed WAV path simpler, while SDL_sound remains available as the fallback for WAV variants or other formats the native decoder does not support.

So this PR is not intended to fully explain or fix SDL_sound itself; it makes Lime prefer its dedicated decoder for the WAV case it already supports.

[jgranick]

Is that the audio player begins playing before it's fed PCM data? Maybe there's a need to feed silence if things are still spinning up