.github/ci: build the Windows job in the MSYS2 UCRT64 environment

[lusoris]

Moves the Windows CI job from the deprecated MSYS2 MINGW64 environment to UCRT64.

This PR originally also fixed the GCC 14+ / Clang build break in vif_buffer_alloc() (#1630). That was resolved on master by #1641 (8e7a1ac4e), so the branch is rebased onto it and that commit is dropped; one commit is left.

Why

setup-msys2 warns on every run of the Windows job (see the annotations of this run on master):

[msystem-mingw64] MINGW64 is deprecated. Migrate to UCRT64 or CLANG64.

UCRT64 keeps the MinGW-w64 GCC toolchain and links against the Universal C Runtime instead of msvcrt.dll, so it is the like-for-like replacement.

What changes

• .github/workflows/windows.yml: the matrix entry (msystem: UCRT64), its package prefix (mingw-w64-ucrt-x86_64) and the release-upload condition that names the environment. The ccache key and the artifact name derive from matrix.msystem.
• resource/doc/windows.md, which mirrors the workflow, names the UCRT64 packages.

One visible effect: the artifact is named UCRT64-vmaf instead of MINGW64-vmaf. The release asset is still vmaf.exe.

Validation

I ran this branch's windows.yml on a windows-latest runner in my fork, on top of master 8e7a1ac4e (run): GCC 16.2.0 in UCRT64, build and install succeed, meson test 21/21, vmaf.exe links ucrtbase.dll, and the run has no deprecation annotation. Rebased on master 9e48141 (2026-10-02): the upstream commits since 8e7a1ac (up to 9e48141) do not touch windows.yml or resource/doc/windows.md, so the diff and the run above are unchanged; the run was not repeated on 9e48141 (it needs a Windows runner). The only difference to this branch is that the fork requires actions pinned to commit SHAs, so that run uses the same five actions by SHA; the build steps are unchanged.

The workflow run on this PR still needs a maintainer's approval.

[lusoris]

Rebased onto 8e7a1ac. #1641 resolved the build break this PR was opened for, so I dropped that commit; what is left is the move of the Windows job from MINGW64 to UCRT64 (one commit, description updated, re-run on a Windows runner linked there).

[lusoris]

Rebased onto acdd937; the new head is 8a2a419. The conflict was in .github/workflows/windows.yml and resource/doc/windows.md: upstream's workflow now has MSVC jobs next to the MSYS2 one, and the guide has an MSVC section. I took upstream's files and re-applied only the MSYS2 change: the matrix entry is msystem: UCRT64 with the package prefix mingw-w64-ucrt-x86_64, and the MSYS2 section of the guide names the UCRT64 shell and packages. The MSVC jobs are untouched. Two statements of the description no longer apply: the workflow no longer has a release-upload condition naming the environment, and the artifact name is the fixed mingw-vmaf, so it does not change.

I did not run the Windows job on the rebased head. I pushed it to my fork to run it there, but the fork's Actions policy rejected the third-party actions at job setup (actions/checkout@v7, actions/cache@v6, msys2/setup-msys2@v2 and the others), so all three Windows jobs failed before any build step. The earlier UCRT64 run linked in the description is for the previous head, on the old workflow. Only the workflow file and the guide changed, no source.