Cubeb: Initialize COM on init

[JordanTheToaster]

Description of Changes

Initializes COM on cubeb init.

Rationale behind Changes

Updating to SDL 3.2.24 exposed a bug with our cubeb implementation as we didn't initialise COM causing the GS dump runner to crash.

"Cubed's WASAPI doesn't initialise COM on init (it's documented that we should do that)
This is normally fine as we call CoInitializeEx in VMManager::Internal::CPUThreadInitialize()

GSRunner, however, calls CPUThreadInitialize() in the main thread, and then starts a different thread to run the VM on
As COM needs to be initialised per thread, that meant the VM thread didn't have COM initialised.

As it happened, SDL was initialising COM when setting up Windows.Gaming.Input (and thus hiding the above issue)
Between the 2 SDL versions, the default value for the hint SDL_JOYSTICK_WGI was switched from true to false
Thus, SDL stopped needing to initialising COM, exposing our bug"

Suggested Testing Steps

Test to see if the dump runner works correctly and audio on Windows works as expected.

Did you use AI to help find, test, or implement this issue or feature?

No

[TheLastRar]

We should probably call CoUninitialize() if cubeb_init fails but initialising COM succeeded.

And also in DestroyContextAndStream() if m_context is not null

[TheTechnician27]

@TheLastRar How does this interact, if at all, with #13366?

[TheLastRar]

No interaction, but I am testing an alternative to this pr

[CookiePLMonster]

We should probably call CoUninitialize() if cubeb_init fails but initialising COM succeeded.

And also in DestroyContextAndStream() if m_context is not null

wil::unique_couninitialize_call can be used for that, just careful with using wil::CoInitializeEx as it considers "already initialized" an error. EyeToy for example uses it.