for the rejected count

Fix for MAINT-8119 - this bug morphed from a packaging issue to being all about audio not playing when a media stream started.  There is some as yet, unknown interaction between the volume catcher code in the CEF plugin and the VLC volume controls. The fix for now is to add a Windows call to the VLC code that sets the process volume explicitly.  Later we will address the volume catcher code, move it to a common spot so both CEF and LibVLC can use the same bytes

Fix for MAINT-8148 - AVI fails to play. For Windows, the x-msvideo MIME type was pointed at CEF which is unable to play it.  Switching that to LibVLC made it work as expected. It was already switched on macOS

MAINT-8119 Fix. A change elsewhere in the viewer_manifest.py script that copies files into the right place after a build impacted the fragment of code that copies over the VLC runtime files (Libvlc.dll, libvlccore.dll and the VLC plugins dir) and they never made it to the right place. This change restores that copy

A change elsewhere in the viewer_manifest.py script that copies files into the right place after a build impacted the fragment of code that copies over the VLC runtime files (Libvlc.dll, libvlccore.dll and the VLC plugins dir) and they never made it to the right place. This change restores that copy

On Windows, when logged in with a non-ASCII username, every one of the three
documented APIs -- SHGetSpecialFolderPath(), SHGetFolderPath() and
SHGetKnownFolderPath() -- fails to retrieve any pathname at all. We cannot
account for the fact that the oldest of these continues to work with the
release viewer and within a Python script (though not, curiously, from a
Python interactive session). With a non-ASCII username, they consistently fail
when called from an Alex Ivy viewer build: "The filename, directory name, or
volume label syntax is incorrect."

Empirically, with a non-ASCII username, the preset APPDATA and LOCALAPPDATA
environment variables are also useless, e.g. c:\Users\??????\AppData\Roaming
where those are, yup, actual question marks.

Empirically, the VMP is able to successfully call SHGetFolderPath() to
retrieve both AppData\Roaming and AppData\Local. Therefore, we make the VMP
set the APPDATA and LOCALAPPDATA environment variables to the UTF-8 encoded
correct pathnames. Instead of calling SHGetSomethingFolderPath() at all, make
LLDir_Win32 retrieve those environment variables.

Make LLFile::mkdir() treat "directory already exists" as a success case. Every
single call fell into one of two categories: either it didn't check success at
all, or it tested specially to exempt errno == EEXIST. Migrate that test into
mkdir(); eliminate it from call sites.

Make LLDir::append() and add() convenience functions accept variadic
arguments. Replace add(add()...) constructs, as well as clumsy concatenations
of directory names and getDirDelimiter(), with simple variadic add() calls.

which is required to free the pointer returned by SHGetKnownFolderPath().

SHGetSpecialFolderPath() is deprecated, and empirically it appears to be
failing when the user name contains non-ASCII characters. The relevant
Microsoft documentation pages recommend calling SHGetKnownFolderPath()
instead.

Also, the SHGetSpecialFolderPath() calls had no error checking or reporting,
which is why we can only say it "appears to be" failing. Make sure that if
SHGetKnownFolderPath() fails, at least we try to tell somebody about it.