WIP: Add WASAPI loopback capture devices

[CalcProgrammer1]

This pull request adds loopback support to the WASAPI driver. It gets a list of render (output) devices when probing capture devices and sets a member flag to indicate they are loopback devices. It then opens them with the AUDCLNT_STREAMFLAGS_LOOPBACK flag. I was able to use alrecord.exe to record what was coming out of my speakers.

Doesn't work correctly when speakers are set to more than 2 channels. I have a 7.1 headset and having it in surround mode kept throwing an invalid format error.

I wouldn't merge this yet until I do more testing.

[nurupo]

This would be very useful addition to OpenAL-Soft, thank you for the work!

By the way, it would seem like you have unnecessarily changed the whitespace formatting in the CaptureDevices section, e.g. & in

[name](const DevMap &entry) -> bool

vs

[name](const DevMap& entry) -> bool

and

std::wstring wname{utf8_to_wstr(name)};

vs

std::wstring wname{ utf8_to_wstr(name) };

and maybe more. These changes also got carried over to the new LoopbackDevices section.

[CalcProgrammer1]

I can double check those whitespace issues. I'm guessing Visual Studio did its unnecessary auto-reformatting nonsense when I copy-pasted some code.

[kcat]

From what I'm reading, this won't work on Windows versions prior to 10:

https://docs.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-initialize

On Windows versions prior to Windows 10, a pull-mode capture client will not receive any events when a stream is initialized with event-driven buffering (AUDCLNT_STREAMFLAGS_EVENTCALLBACK) and is loopback-enabled (AUDCLNT_STREAMFLAGS_LOOPBACK). If the stream is opened with this configuration, the Initialize call succeeds, but relevant events are not raised to notify the capture client each time a buffer becomes ready for processing.

Which the record thread relies on to get samples properly. The suggested workaround doesn't seem very practical.