Fix compilation with MinGW on Windows

[shoogle]

Errors fixed:

src/framework/ui/internal/platform/windows/windowsplatformtheme.cpp: In member function 'void mu::ui::WindowsPlatformTheme::startListening()':
src/framework/ui/internal/platform/windows/windowsplatformtheme.cpp:78:62: error: cannot convert 'const wchar_t' to 'LPCSTR' {aka 'const char'}
     if (RegOpenKeyEx(HKEY_CURRENT_USER, windowsThemeKey.c_str(), 0,
                                                              ^

src/libmscore/scorefile.cpp: In member function 'bool Ms::MasterScore::saveFile(bool)':
src/libmscore/scorefile.cpp:460:72: error: invalid cast from type 'QByteArray' to type 'LPCTSTR' {aka 'const wchar_t*'}
             SetFileAttributes((LPCTSTR)backupDirNativePath.toLocal8Bit(), FILE_ATTRIBUTE_HIDDEN);
                                                                        ^

Edit: The errors arose because we were using these aliases from the Windows API:

• SetFileAttributes
• LPCTSTR

When UNICODE is defined these aliases point to 'W' (wide) symbols that provide Unicode support (UTF-16):

• SetFileAttributesW
• LPCWSTR

However, if UNICODE is not defined then the aliases point to the narrow ANSI (8-bit) symbols:

• SetFileAttributesA
• LPCSTR

The fix is to explicitly use the wide symbols (i.e. don't use the aliases). The wide symbols are available on Windows even when UNICODE is undefined; it's just the aliases that are different. The aliases are only needed for compatibility with code written prior to Windows NT, so it's probably best to avoid them.

[Jojo-Schmitz]

Does it also solve the warning?

src/framework/ui/internal/platform/windows/windowsplatformtheme.cpp:41:126: warning: cast between incompatible function types from 'FARPROC' {aka 'int (__attribute__((stdcall)) *)()'} to 'fnRtlGetNtVersionNumbers' {aka 'void (__attribute__((stdcall)) *)(long unsigned int*, long unsigned int*, long unsigned int*)'} [-Wcast-function-type]
     = reinterpret_cast<fnRtlGetNtVersionNumbers>(GetProcAddress(GetModuleHandleW(L"ntdll.dll"), "RtlGetNtVersionNumbers"));

Edit: no it does not. Not the scope of this PR I guess.