audio: Don't force minimum device spec.

[icculus]

• I confirm that I am the author of this code and release it to the SDL project under the Zlib license. This contribution does not contain code from other sources, including code generated by a Large Language Model ("AI").

Now we allow physical devices to reopen at a higher spec if necessary.

Added test/testdynaudioreopen.c to stress test this change.

Fixes #14558.

The reason for this: currently, physical device opens have a minimum spec (CD quality: S16, 2 channels, 44100Hz), so if something comes through first and opens it at a super-low quality, it doesn't ruin the rest of the app. For example, VoIP gets there first wanting mono/8000Hz, or an ancient game wants Uint8/11025Hz but wants to play the game's CD audio from MP3 files at Float32/44100Hz.

With this PR, if the device gets a second open request at a higher quality, it'll close the physical device, reopen it in a better format, readjust any bound audio streams, and send the appropriate SDL_EVENT_AUDIO_DEVICE_FORMAT_CHANGED events.

This way, apps can attempt to open at lower-than-CD quality if that's all they need, and if something comes along later needing more, everything can be accommodated.

This is still draft, because I want to test this across a bunch of platforms, and there's a question of what to do if we close the device and then fail to reopen it, even back at the original format...in theory we can "recover" by spinning our own thread to run the Zombie implementation, but that's getting hairy.

Also worth noting: On my Fedora 44 system, the device is opening at one specific format and refuses to budge higher or lower (but this format is different between ALSA, PulseAudio, and Pipewire!). It might be worth adding a backend function to ask "can I change to this specific format?" And if the backend says no, don't bother trying.

It might also be worth adding a function to say "change this open device to this format if possible" and not mess with tearing down the whole device at the higher level...but I haven't explored that route yet, under the assumption that most backends will need to tear everything down anyhow.

But even in the worst case, this PR does tell us that the system can tolerate reopening a live physical audio device. Here is what my speakers sound like closing/opening the device every two seconds, recorded from a microphone in the room:

dynreopen.mp3

There's an obvious half-second when it's closing/reopening, but everything keeps working, and since I suspect this is largely going to happen once or twice at startup for apps that need this, I'm willing to live with it.

We're going to move the "Implement device streams" task on #14558 to a new issue and let this PR resolve the original report. Notably, backends that deal with streams won't need this functionality, since we won't need to reopen a physical device to adjust format; they'll just get a new stream at whatever format on the same hardware, and the platform will deal with conversion, etc.