Add Windows build automation script and update QML comment for URI handling

[aramadan0096]

[ 329: Add a Windows build automation script ]

Linked issues

Fixes #329

Summarize your change.

Adds scripts/build_windows.ps1, which automates the sequence in
docs/reference/build_guides/windows.md end to end: preflight checks, Visual Studio
discovery, Qt 6.5.3 installation via aqtinstall, vcpkg clone/pin/bootstrap,
CMakeUserPresets.json generation, entering the VS Developer Shell, configure, build,
NSIS packaging, and optionally building and running the tests.

Every phase can be skipped (-SkipQt, -SkipVcpkg, -SkipConfigure, -SkipBuild) so
the same script serves both a cold first build and fast iteration. -CheckOnly reports
the state of the toolchain without modifying anything.

Also adds build_logs/ and CMakeUserPresets.json.bak to .gitignore, both written by
the script.

Describe the reason for the change.

The Windows guide is a long manual sequence, and several environment details it cannot
reasonably cover only surface deep into a multi-hour build. The script turns each into an
early, explicit check. Detail is in #329; the substantive one:

Enter-VsDevShell and vcpkg can select different MSVC toolsets. The developer shell
honours Microsoft.VCToolsVersion.v143.default.txt, vcpkg picks up
Microsoft.VCToolsVersion.default.txt. Where those differ, the dependencies and xSTUDIO
are compiled with different toolsets. Following the guide exactly on my machine gave
dependencies at 14.42.34433 and xSTUDIO at 14.40.33807, and since only 14.42 shipped
atlmfc, the build failed about 50 minutes in:

src\audio\src\windows_audio_output_device.cpp(4): fatal error C1083:
Cannot open include file: 'atlbase.h': No such file or directory

The ATL component was installed — just not for the toolset the dev shell chose. The
script enumerates installed toolsets, selects the newest one carrying ATL, pins it with
-vcvars_ver, and fails at preflight with installer guidance if none has it.

Smaller ones it also handles: cmake/ninja not actually being on PATH after
Enter-VsDevShell (on my machine ninja resolved to Strawberry Perl's copy, beside a
MinGW gcc/ar); a CMakeCache.txt generated for a different source tree; a vcpkg root
locked by another build, which otherwise looks identical to slow progress; and a
dependency download that fails its hash check because the host served an anti-bot page.

Describe what you have tested and on which operating system.

Windows 10 Pro 22H2 (19045), Ryzen 9 5950X, VS 2022 Community (MSVC 14.42.34433),
Qt 6.5.3 msvc2019_64, NSIS 3.x, preset WinNinjaRelease.

Exercised for real, not dry-run:

• Qt 6.5.3 installed from scratch by the script via aqtinstall (~34s) on a machine that
  had only Qt 5.15.2.
• vcpkg cloned, fetched, pinned to the builtin-baseline commit
  c2aeddd80357b17592e59ad965d2adf65a19b22f, and bootstrapped.
• Full clean configure + build + package → build/xSTUDIO-1.3.0-win64.exe (223.6 MB),
  plus build/bin/xstudio.exe and build/run_xstudio.bat.
• Incremental rebuild (-SkipVcpkg -SkipConfigure): 8m33s. Configure alone drops from
  44m12s to 1m22s once the vcpkg binary cache is warm.
• -BuildTests / -RunTests: configure with BUILD_TESTING=ON, build helpers_test,
  run ctest -R utility_helpers_test.
• -CheckOnly, and the failure paths for a stale cache, a missing vcpkg, and a toolset
  without ATL.

Not tested: the Visual Studio generator presets (WinRelease/WinDebug) — the script
adds --config for those, but only the Ninja presets were exercised. Not tested on
Windows 11.

Two issues encountered that are not caused by this change, but which anyone building
on Windows will hit right now:

1. code.videolan.org serves an anti-bot challenge page to command-line downloads, so
   vcpkg's x264 fetch fails its SHA512 check. It has to be downloaded once in a browser
   into the vcpkg downloads directory. The script detects the hash failure and prints that
   remedy rather than a raw CMake trace.
2. With BUILD_TESTING=ON, contact_sheet_test does not compile — winsock2.h is
   included after windows.h, giving ~100 redefinition errors (sockaddr, fd_set,
   WSAData, ...) and C1003. This breaks --target all, so the docs' "some tests
   currently fail or time out" understates it for that target. Happy to open a separate
   issue.

Add a list of changes, and note any that might need special attention during the review.

Change	Notes
scripts/build_windows.ps1 (new)	799 lines, PowerShell 5.1 and 7.x compatible
.gitignore	adds build_logs/, CMakeUserPresets.json.bak

Worth attention:

• Toolset pinning. The script auto-selects the newest ATL-carrying toolset and pins it
  via -vcvars_ver; -MsvcVersion overrides. If the project would rather document the
  required component than auto-select, that is an easy change — but note the current
  default silently mixes toolsets between dependencies and the application.
• vcpkg root is overridable. CMakePresets.json hardcodes ${sourceDir}/../vcpkg.
  When -VcpkgRoot points elsewhere the script emits a CMAKE_TOOLCHAIN_FILE override
  into CMakeUserPresets.json, so a project can use a dedicated vcpkg checkout and avoid
  lock contention with other builds. The binary cache is keyed by ABI hash rather than by
  root, so a separate root still reuses everything already built.
• CMakeUserPresets.json is rewritten. Other presets in the file are preserved and a
  .bak is written first, but the script does take ownership of its own preset entry.
• Test failures are reported, not fatal. -RunTests warns on a non-zero ctest result
  and the script still exits 0, matching the docs' note that a clean run is not expected
  yet. Say the word if you would rather it propagate.
• No CI is added here. The script is a developer convenience. It could back a Windows
  build job later, which would have caught both issues noted above.

If possible, provide screenshots.

N/A — command-line change. Final summary from the packaging run:

Item             Status  Detail
----             ------  ------
MSVC toolset     ok      14.42.34433
Qt 6.5.3         ok      C:\Qt\6.5.3\msvc2019_64
Installer        ok      build\xSTUDIO-1.3.0-win64.exe
Dev launcher     ok      build\run_xstudio.bat

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: aramadan0096 / name: Ahmed Ramadan (6cbbee9)

[tedwaine]

Thanks for this contribution. Looks great, just what we needed to lower the bar for Windows users. I will test on my own Win10 and Win11 systems and merge pending that.

[tedwaine]

Thanks for this one, @aramadan0096 - it worked 1st time on my Win11 machine too. This makes building and using xSTUDIO much more accessible for many.