QAudioDevice min/max sample rate API is inappropriate and also incorrect

Firstly, audio hardware does not generally support arbitrary sample rates in a range. Audio hardware supports a finite list of sample rates. Therefore Qt6's new API for reporting min/max sample rate (as opposed to Qt5 providing a list of sample rates) does not reflect reality and is inappropriate. `QAudioDevice` should return a finite list of supported sample rates, matching the hardware capabilities. If it's not possible to determine the finite list with a given back-end, then an alternative is to keep the min/max API but add e.g. `supportedNativeSampleRates()` to return a list when available.

If an application wishes to support arbitrary non-native sample rates then it can use an appropriate resampler as desired. This is not a function of the I/O hardware.

It also presents a UX issue when presenting lists of common sample rates to select from (which is generally more desirable than a text box with an arbitrary number).

Secondly, regardless of appropriateness, the reported min/max values aren't actually correct. They appear to just be hardcoded as 11250 to 96000.

I have a system here which includes a couple of devices for which this is not correct:

• Integrated Intel HD Audio - A common device that supports 6kHz to 192kHz playback rates. Qt6 lists minimum as 11250 (not 6000) and maximum as 96000 (not 192000).
• Focusrite Scarlett 18i8 - A prosumer-grade USB audio interface that support up to 192kHz I/O. The sample rate is configurable on hardware. When set to any rate (including 176400 and 192000), Qt6 again lists minimum as 11250 and maximum as 96000.

Qt6 fails to recognize the 192kHz (and also low-end 6kHz) rates of these devices, and in fact appears blind to the actual supported sample rates of the devices, always returning 11250-96000 for any device.

Thirdly (or second-and-a-halfly), the supported range reported by QAudioDevice is not only incorrect wrt reality, it also appears incorrect wrt to the actual capabilities of QAudioSources/QAudioSinks, which can be initialized with arbitrary sample rates outside the range. This will always succeed, and `format()` on the source/sink will confirm the arbitrary sample rate.

In summary:

• The API needs to be reverted to report a finite list of sample rates.
• The reported sample rates need to be correct.
• QAudioSource/QAudioSink need to report whatever actual sample rate they are using.

The consequence of these issues is, in its current form, the QAudioDevice sample rates are entirely meaningless, and no range/set of valid sample rates can be determined, thus defeating the purpose of having sample rate be reported in the first place. Applications must be developed as if sample rate is a non-reported capability.