[vcpkg-scripts] Update msys2

[dg0yt]

Semi-automated update from vcpkg-ci-msys2[*].

Needed to stay ahead of expiring downloads.

Major changes:
gfortran -> 13.2
msys2-runtime -> 3.4.9-3 (upstreamed fixes for flaky "Bad address" errors when invoking Windows program from MSYS2)
pkgconf -> 2.1 (upstreamed fixes for search order and link lib order)
python -> 3.11

[dg0yt]

Hm, the final ffmpeg error is

D:/installed/x64-windows/tools/pkgconf/pkgconf.exe --exists --print-errors aom >= 1.0.0
/d/buildtrees/ffmpeg/src/n6.0-c7510d6860.clean/configure: line 995: D:/installed/x64-windows/tools/pkgconf/pkgconf.exe: Bad address
ERROR: aom >= 1.0.0 not found using pkg-config

but earlier invocations of pkgconf worked, and the Bad adress errors start earlier, too:

check_func_headers bzlib.h BZ2_bzlibVersion -lbz2
test_ld cc -lbz2
test_cc
BEGIN ./ffconf.IrXuJGdW/test.c
    1	#include <bzlib.h>
    2	#include <stdint.h>
    3	long check_BZ2_bzlibVersion(void) { return (long) BZ2_bzlibVersion; }
    4	int main(void) { int ret = 0;
    5	 ret |= ((intptr_t)check_BZ2_bzlibVersion) & 0xFFFF;
    6	return ret; }
END ./ffconf.IrXuJGdW/test.c
cl.exe -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -DPIC @D:/buildtrees/ffmpeg/x64-uwp-rel/cflags.rsp -nologo -DWINAPI_FAMILY=WINAPI_FAMILY_APP -D_WIN32_WINNT=0x0A00 -DHAVE_UNISTD_H=0 -ID:/installed/x64-uwp/include -c -Fo./ffconf.IrXuJGdW/test.o ./ffconf.IrXuJGdW/test.c
/d/buildtrees/ffmpeg/src/n6.0-c7510d6860.clean/configure: line 995: /c/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.37.32822/bin/Hostx64/x64/cl.exe: Bad address

The common thing is that both pkgconf.exe and cl.exe are invoked from within MSYS2 bash, so it could be an MSYS2 runtime issue.

[Neumann-A]

pkgconf -> 2.0 (with fix for search order regression)

Non of the pkgconf PR went through so there seem to be still bugs in latest pkgconf.

[dg0yt]

Non of the pkgconf PR went through so there seem to be still bugs in latest pkgconf.

Unrelated to "Bad address".

• Upstream pkgconf has a search order regression since 2.0.0: Issue with PKG_CONFIG_PATH resolving past 2.0.0 pkgconf/pkgconf#326, Fix search order pkgconf/pkgconf#327.
  MSYS2 fixes this with a patch now. That's why I made this PR now.
• The remaining regressions in [pkgconf] Update to 2.1.0 #34228 are from CMake reordering link libraries which are imported from pc files because it doesn't assume any dependencies. I fixed this for graphviz by adding dependencies unless they are explicit, 6a15df6.
  IIRC this started in some CMake 3.2x. This may explain why qtinterfaceframework has been flaky before. The relevant link libraries are picked via pkgconfig in qtmultimedia... IIRC there was a connection to link groups support, but I can't remember what's the chicken and what's the egg.
  I'm really close to forking or wrapping FindPkgConfig.cmake :-(

[Neumann-A]

I'm really close to forking or wrapping FindPkgConfig.cmake :-(

That needs to be done either way if vcpkg wants to correctly support multi config for it some day.

The remaining regressions in #34228 are from CMake reordering link libraries which are imported from pc files because it doesn't assume any dependencies.

Maybe should be reported to CMake upstream?

Googled a bit around and it seem that wrong quoting can also result in "Bad adress" errors. So it will be really hard to tell where the problem is. Maybe switch around the bzip and zlib tests and see if the bzip test or the zlib test is now failing.

[dg0yt]

Nightly CI is now complaining about libcrypt being removed the msys2 index. Time to update.
But pkgconf 2.0 is still unusable because of pkgconf/pkgconf#322. I will try to remove this part of the update.

[dg0yt]

My fixes for pkgconf and msys2-runtime are finally accepted into upstream sources... I hope the flaky "Bad Address" issues are resolved then.

[dg0yt]

jkqtplotter: baseline regression, #35319

[MehdiChinoune]

Could you take the opportunity and use mingw-w64-i686-pkgconf/libwinpthreads on x86 and mingw-w64-x86_64-pkgconf on x64
somthing similar to #24160, except that the file is scripts/cmake/vcpkg_find_acquire_program(PKGCONFIG).cmake

[dg0yt]

Could you take the opportunity and use mingw-w64-i686-pkgconf/libwinpthreads on x86 and mingw-w64-x86_64-pkgconf on x64 somthing similar to #24160, except that the file is scripts/cmake/vcpkg_find_acquire_program(PKGCONFIG).cmake

vcpkg_find_acquire_program(PKGCONFIG).cmake is subject of #35299.

These PRs used to have different blockers. That's why they exist in isolation. I can create a third, integrated PR. But I don't want to delay any of these isolated PRs now. Every day of delay means more users which will run into future msys2 download errors from not updating vcpkg early enough. And every day is another chance for the vcpkg maintainers to merge new baseline regressions...

[dg0yt]

Included in #35331 (proposed).

[dg0yt]

Merged with #35331.