Windows on ARM fixes

[qyot27]

Some fixes are to get certain things to build (Shibatch) or skip building (VDubFilter), some are revising the documentation, and the most important one: explicitly blocking the use of MSVC to build ARM binaries. I'm tired of having to reiterate why person X's attempt at loading plugin Y failed on x86(-64) because they built it with MSys2 and the plugin is a C++ plugin.

Windows on ARM is different, though; it's still a relatively niche platform and we have never actually done a proper release for it (just an experimental build or two a few versions back that was just an archive, not an installer), much less one that's allowed an entrenched plugin ecosystem to arise around using MSVC on there, too. In a lot of cases of previously-unported plugins, supporting Windows on ARM is going to require plugin devs to modify their code to section off the x86 SIMD, so if they have to go to that length, switching to llvm-mingw or GCC (once support for Windows on ARM lands in a stable GCC release) as the compiler is not that much more difficult. Especially considering the fact that WSL2 is right there on modern Windows 10 and 11, and the Windows on ARM target computers are all officially running Windows 11 anyway¹ (Windows 10 on ARM does exist, but the mass-market products with it were underpowered netbooks or IoT devices, and people beating it with a hammer until it would run on a Raspberry Pi...which is a painful experience).

¹the Snapdragon [X|X Plus|X Elite] laptops, all of which have the Copilot+ branding, as those chips have competitive performance and make Windows on ARM actually worth using.

The way the check happens is that it allows MSVC (or ClangCL) to work if it detects that it's being built for an x86 or x64 target. If it detects anything else, it stops the configuration dead and tells the user to use MinGW (which would be ARM64, but if Microsoft does anything weird in the future and adds other arches like RISC-V, we're already ready for it). There's also a block in avs/config.h so that plugins including the header will fail to build if it's targetting the wrong combination of compiler, OS, and architecture.

Because only MinGW plugins can be built for ARM, the workaround for GCC core builds having their own plugin directory/registry entry becomes irrelevant, so again, that registry entry/directory is only enabled for searching on X86.

The x86(-64) external deps guide now also includes instructions to install pkgconf without the user having to piggyback MSys2's environment.

The InnoSetup script for ARM probably needs some trimming down, but just getting it in here is a first step.

[pinterf]

Good job, FYI: VapourSynth has just got a PR on arm stuff, getcpuflags and intrinsics handling (neon). This may be the next level for us as well.

[qyot27]

I had done some experiments a few years ago to see if simde would allow ease of porting to NEON, but either I was using it wrong (entirely possible, since I almost certainly was) or the codebase/[GCC/Clang] just optimizes extremely well on RISC arches when using the exact same flags (appropriate -march/-mtune flags, and either -O2 or -O3, which also turns on -ftree-vectorize) simde requires using to enable their x86->ARM SIMD translation, so it didn't seem to change the speed all that much.

Actually utilizing ARM intrinsics surely will be faster/more accurate/more tailored anyway. NEON is the obvious baseline, as that's a required part of ARMv8-A, but SVE2 requires ARMv9-A (which is only just now arriving in consumer hardware; the Apple M4 is the first, I think).