Some games with support for the haptic feedback and speaker features of the Sony DualSense controller select the controller's audio output by filtering on the ContainerId IMMDevice property to find one that matches the controller's HID's. This MR allows this information to be accessible from the IMMDevice's property store when the audio driver provides it (none for now, but I intend to add that feature to `winepulse.drv` and maybe `winealsa.drv`)
Windows also stores the property in that registry key, but serializes it as binary instead of storing the string representation. I did not find documentation on that serialization, and while it seems mostly straightforward, there are two bytes I could not understand the meaning of: `{4a412178-e895-11ec-a989-00dbdfb57d1c}` is stored as `48 00 2b b7 01 00 00 00 78 21 41 4a 95 e8 ec 11 a9 89 00 db df b5 7d 1c`. The `01 00 00 00` DWORD seems to always have that same value, and the `2b b7` parts are safe to ignore when reading, but I do not know what meaning they have.
If there are already parts of Wine dealing with such a serialization, I could not find them, but I would gladly use them. Using the proper encoding would also conflict with `VT_BLOB` handling, but I suspect Windows also encodes `VT_BLOB` properties in a similar way than it does for `VT_CLSID`. On that note, Windows' behavior for `PKEY_AudioEngine_DeviceFormat` is different from Wine's, storing it as `41 00 04 00 01 00 00 00 ff fe 04 … 38 9b 71`, while Wine stores the `ff fe … 71` payload directly.
-- v2: mmdevapi: copy ContainerID from audio driver if available mmdevapi: decode ContainerId property to CLSID in MMDevice_GetPropValue mmdevapi: support VT_CLSID for containerId property in MMDevice_SetPropValue