[Coastrnaut]

Related to #1058

Configuring libprojectM with CMAKE_SYSTEM_NAME=WindowsStore currently fails to compile, so a UWP app has to patch the build (frontend-uwp#7 does this from its own CMakeLists.txt). This makes libprojectM build for UWP as is, and adds a CI job so it stays that way.

Changes

• CRT deprecation errors: UWP projects enable SDL checks, which turn the CRT deprecation warnings into errors, in the vendored code (strdup, stricmp, fopen) and in GLProbe.cpp (sscanf). _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_WARNINGS are now defined for WindowsStore builds.
• Windows defines: NOMINMAX, WIN32_LEAN_AND_MEAN and STBI_NO_DDS were only defined for PLATFORM_ID Windows; they're now also defined for WindowsStore.
• GLES: UWP apps can't use desktop OpenGL, and glad's WGL loader doesn't compile there, so ENABLE_GLES is forced on, like for Android.
• DLL loading: DynamicLibrary_win32.cpp uses LoadLibraryEx, GetModuleHandle and GetSystemDirectory, which UWP apps can't call. The new DynamicLibrary_uwp.cpp loads the EGL/GLES provider (e.g. ANGLE) from the app package with LoadPackagedLibrary, using the existing kAllEglModuleNames list. DynamicLibrary_win32.cpp is skipped for UWP via a PLATFORM_WINDOWS_STORE_APP macro based on WINAPI_FAMILY_PARTITION.
• getenv: UWP apps have no process environment, so EnvFlagEnabled() treats all GL resolver flags as unset there.
• CI: a build-uwp job in build_windows.yml builds Debug and Release for x64 and Win32 on windows-2022 with the v142 toolset (the setup frontend-uwp's CI uses).

Desktop builds compile the same code as before.

Testing

• UWP x64 and Win32 Release builds succeed locally (VS 2026, v145 toolset) without any workarounds; master fails with 28 errors. The DLLs only import API sets and _APP CRT libraries available to UWP apps (including LoadPackagedLibrary), no opengl32, LoadLibraryEx or GetModuleHandle. I don't have the v142 toolset locally, so the new CI job is its first v142 build.
• Desktop: unit tests pass, the default GL resolver still works, and all 14,536 presets from cream-of-the-crop, en-d, milkdrop-original and projectm-classic give the same shader compile/link results and preset load failures as master.

Note for frontend-uwp#7: it compiles its own DynamicLibrary_uwp.cpp in place of DynamicLibrary_win32.cpp. With this change that would give duplicate symbols, so once its submodule moves past this, it should drop that workaround (the others become unnecessary but don't break anything).

Retested on current master (2026-11-12)

• Unit tests: 164/164 libprojectM and 98/98 playlist tests pass.
• Presets: I loaded all 14,536 presets from cream-of-the-crop, en-d, milkdrop-original and projectm-classic one after another with this branch and with master (GL 3.3 core, RTX A6000, preset folders as texture search path, 30 frames each with fixed audio, frame times and random seeds; the seeds are a local patch only, identical on both sides). Shader compile/link results, failed loads and all rendered frames are identical to master.
• Together with my other PRs: All my open PRs (Fix calling convention of glGetStringi pointer in GLProbe #1059 to Build for Windows Store (UWP) without app-side workarounds #1065, Return int from the NaN-safe multiplication of two ints #1067 to Fix shaders that declare or name samplers through macros #1072, Build Apple frameworks for iOS, tvOS, watchOS and visionOS, and support EAGL contexts #1075, Don't shift the blur textures by Direct3D's half-pixel offset #1078 and Render with 10 bits per color channel if the target framebuffer has more than 8 #1079) merge with each other and with master without conflicts. Merged together (all except Render with 10 bits per color channel if the target framebuffer has more than 8 #1079, which I opened after this run), they build on desktop GL and GLES, all unit tests pass, and the corpus gives 0 failed loads, 0 shader compile/link failures and 0 GL errors in an OpenGL ES context, with and without textures.