Add WavPack support

[menguele]

The only proper lossless codec supported now in Raylib is Flac, and while it is fine as it is, I feel WavPack could fill both lossy and lossless codec duty, portraining a hybrid mode which requires a correction file (.wvc) to "restore" the "lost" bits. It's not the only codec to have a similar hybrid mode, OptimFROG has a mode inspired by WavPack's, but given the nature of its slower decoder and the fact that it's closed-source, a WavPack decoder is more apt to be added to Raylib.

It's lossy part isn't that efficient compared to its competitors, in this case MP3, Vorbis and QOA. But the bandwidth and space savings could be great:

Fly To The Leaden Sky (from Battle Garegga)

Size	Extension
39M	wav
31M	flac
7.5M	mp3
6.3M	ogg
7.7M	wv
23M	wvc

Stab and Stomp (from Battle Garegga)

Size	Extension
45M	wav
38M	flac
7.9M	mp3
6.4M	ogg
8.9M	wv
29M	wvc

All of the encoding were handled by FFmpeg, utilizing it's reccomended encoder, except WavPack (.wv and .wvc), in those cases it was done with official command line utils as FFmpeg doesn't support correction files.

As you can see, WavPack's lossless compression is competitive with Flac. I don't expect most people with other codecs to change, but those who see a good use for it probably will: Distribution of lossless audio. One could release a DLC advertising lossless music, and it's just the correction files, saving a bit of both bandwidth and drive space, for both user and developer; libwavpack even supports streaming the correction bytes through the internet.

With a good implementation, it would be a seamless procedure, as libwavpack has a function to open the WavPack and "get" the correction file, just setting a flag, although it standardly need to be with the same name of the file but with ".wvc" extension.

With WavPack support addition in mind there are two ways to proceed:

1. Incorporate libwavpack on the source tree.
2. Develop a minimal wavpack decoder.

The first would be probably the simplest to do, gitclone wavpack's source into a subdirectory, modify cmake to compile only it's libraries and work from there within raudio.h to implement what it needs for decoding and whatsoever. But it would clash with Raylib's design to have minimal dependencies and its preference to single-file headers/libs.

The second would require the most work, given the fact that FFmpeg doesn't support correction files/hybrid mode, I think it would be the hardest thing to implement, but without it I don't see the point in adding it to Raylib.

[raysan5]

@menguele I'm afraid raylib only uses single-file header-only self-contained C libraries for file formats support, is that option available for WavPack?

Even though, it seems a very specific request for a very specific use case. Users with WavPack requirements can implement it on their programs, there is no need to be provided by raylib.

[menguele]

I'm afraid raylib only uses single-file header-only self-contained C libraries for file formats support, is that option available for WavPack?

Currently no, even the tiny decoder, made by WavPack's developer, have multiple files.
Was looking into developing a single-file library to decode, but there isn't much time available to me atm.

Even though, it seems a very specific request for a very specific use case. Users with WavPack requirements can implement it on their programs, there is no need to be provided by raylib.

Yeah, that could be the case.