Windows: COM initialization fixes

[CookiePLMonster]

Description of Changes

Cleans up COM initialization for the sake of Cubeb and EyeToy. The following changes were made:

1. On Windows, all uses of Cubeb in the USB mic and SPU2 outputs now explicitly request MTA COM model.
2. As Qt initializes the main thread to STA, Cubeb device enumeration has been moved to the emulation thread. Cubeb initialized fine in STA, but it's against the docs, so maybe it would break sometime in the future.
3. COM initialization for EyeToy was cleaned up and a bug was fixed - EyeToy that is enabled in options but not started by the game would call CoUninitialize on edit without a corresponding CoInitializeEx call beforehand, breaking the COM state.

Replaces #13364.

Rationale behind Changes

Code correctness.

Suggested Testing Steps

1. Ensure that Cubeb devices enumerate and audio works (on Windows).
2. Ensure that USB microphones enumerate and work fine.
3. Ensure that EyeToy starts.

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

No.

[JordanTheToaster]

Cubeb and eye toy still functions correctly on Windows.

[TheLastRar]

Is the global namespace :: needed for CoInitializeEx?

As for cubeb, you are allowing STA (despite the pr description), what made you drop the MTA changes?

[CookiePLMonster]

Is the global namespace :: needed for CoInitializeEx?

No, just a habit.

As for cubeb, you are allowing STA (despite the pr description), what made you drop the MTA changes?

1. Delegating from the UI to emuthread could theoretically result in deadlocks (when blocking), so it's not a great idea.
2. I only allow STA for enumerating devices, and that doesn't create COM objects across threads. Creating Cubeb streams does, and that's why the main CubebAudioStream still wants MTA.

[TheLastRar]

Is the global namespace :: needed for CoInitializeEx?

No, just a habit.

I would personally omit it if it was unneeded, which would align with other uses of Windows API functions.

2. I only allow STA for enumerating devices, and that doesn't create COM objects across threads. Creating Cubeb streams does, and that's why the main CubebAudioStream still wants MTA.

Given Cubeb's recommendation, can a comment be added with the above.

Also, the usb mic can share the cubed instance between the UI and CPU thread, Is this okay given the different apartment types between the two?

[CookiePLMonster]

I would personally omit it if it was unneeded, which would align with other uses of Windows API functions.

I'll change it.

Also, the usb mic can share the cubed instance between the UI and CPU thread, Is this okay given the different apartment types between the two?

As far as I can tell, UI could share the instance from the CPU thread (one that was initialized in MTA), but not vice versa, so it should be fine. Even though it may not look like this, the behaviour of USB mic is effectively unchanged to what we're doing now, and no one ever complained about enumerations failing.

[TheLastRar]

Changes look good, but haven't personally tested

[kamfretoz]

Audio device selection and others still works.

[F0bes]

I think it LGTM