REGRESSION: Audio device name is no longer properly detected in Sound Properties

This ticket is about regression caused by a fix for my previous CORE-19986, and is intended to fix it.

To reproduce the bug, simply:

1. Right click on the Speaker icon in system tray and open "Adjust audio properties".
2. Look at the device name right from the speaker icon. It's not visible, means the name string is empty:
   

1. Switch to "Audio" tab.
2. Now you see that both "Sound playback" and "Sound recording" devices have empty names too:
   

As you can see on the following screenshots, the previous build is unaffected at all:

The last unaffected build is
0.4.16-dev-2537-g9a7f64a,
and it started to occur only since
0.4.16-dev-2538-gb205c04,
as you can see from the screenshots above.

Tested by me with multiple configurations: in VirtualBox 7.1.12 + our inbuilt Intel AC97 driver, VMware Workstation 17.6.4 with VMaudio driver from VMware Tools and on real hardware (Asus-F5R notebook) with Realtek ALC660 HD audio controller + Realtek HD audio codec R2.74.
The problem is confirmed to exist on all of these cases at least, so it actually does not depend on any specific configuration.

The guilty commits is https://github.com/reactos/reactos/commit/b205c041735ab98b7825461f32be8ced38c8b05e, which is authored by me, so I already made a fix locally and will send a new PR with it soon.
To be backported in releases/0.4.16 branch as well.

The problem is, since these strings are actually rad from Registry, they are not displayed correctly obviously because they are missing there (not written properly):

However, no any related debug output in debug.log.

Analysis of the problem:
My previously performed debugging analysis shows that started to occur after my changes, because the reference key name is not created properly due to the wrong symbolic link string passed to SetupDiCreateDeviceInterfaceRegKeyW() function from CreateSymbolicLink() and InstallOneInterface() internal helpers, which are part of SetupDiInstallDeviceInterfaces() (called here: https://git.reactos.org/?p=reactos.git;a=blob;f=dll/win32/setupapi/interface.c;h=4fe98c4cd4e13d601596ae2df79158ef9d085754;hb=HEAD#l374).
It fails on opening reference key, because reference string is already cut from the input symbolic link (since it's already converted to the instance key name). So it actually has no ref string, only a single # pound character, even in the case when ref string actually exists. It obviously fails with NT status 0xc00000034 (STATUS_OBJECT_NAME_NOT_FOUND) because that key simply doesn't exist.
SetupDiCreateDeviceInterfaceRegKeyW() should receive a fully correct symbolic link, not only instance key name with all backslash \ separators replaced by # pounds and cut reference string. It actually should do the transformation from symbolic link to the instance key name (cutting ref string and replacing all \ by #) inside its implementation instead.
My previous changes fixed (and were intended to fix) the wrong behaviour of SetupDiCreateDeviceInterfaceRegKeyW(), but only for the case when it's called from any external module (MS winmm.dll from Windows 2000 SP4 in my case) (since it's exported function, so it's publicly available). They actually did not fix the behaviour properly for another internal usage case described above (SetupDiInstallDeviceInterfaces() and its internal helpers).
My new changes which I'm planning to send via PR, fix the described behaviour for the 2nd usage case too. They mainly do the following things:

1. Create the actual symbolic link, instead of just instance key name (don't replace all \ by # and don't cut reference string from it) inside CreateSymbolicLink(), to pass it in SetupDiCreateDeviceInterfaceRegKeyW() inside InstallOneInterface() later.
2. Fix handling the received symbolic link inside SetupDiCreateDeviceInterfaceRegKeyW() itself. Except it to be the fully unmodified one, instead of transformed to an instance key name. After finding the end of GUID part ('}'), replace the first \ separator of reference string by # pound, and fix cutting reference string code, to avoid invalid/uninitialized characters inside the string's buffer. Copy Reference string in a separately allocated buffer, to open the reference Registry key and free it later.
3. Additionally, change the SetupInstallFromInfSection() call to SetupInstallFromInfSectionW(), since it's actually called with Unicode parameters from Unicode version of SetupDiCreateDeviceInterfaceRegKeyW(). Otherwise, if not precisely specify Unicode version call, it might call ANSI function instead and hence will obviously not work correctly because of that.