Align Windows dev tree with install layout for runtime resource discovery

[OlafRocket]

[ Align Windows dev tree with install layout for runtime resource discovery ]

Linked issues

None.

Summarize your change.

Aligns the Windows build tree with the install layout for all resources
that xstudio looks up via xstudio_root() — fonts, OCIO configs,
snippets, plugin DLLs, third-party QML modules, and Python plugins.
Adds vcpkg's bin/ to the dev launcher's PATH so plugin DLL dependencies
resolve.

Describe the reason for the change.

Running build\run_xstudio.bat from a fresh build on Windows crashes
with exit code 0xC0000005 after FreeType fails to load a font, preceded
by six "module could not be found" warnings from the plugin loader.

Root causes:

1. xstudio_root() on Windows derives <exe-grandparent>/share/xstudio,
   matching the install layout. The 1.2.0 build-system changes migrated
   plugin DLLs and preferences to that layout in the build tree, but
   fonts, OCIO configs, snippets, third-party QML modules, and Python
   plugins were left at build/bin/..., where the runtime no longer
   looks.

2. Plugin DLLs link against vcpkg-built deps (avcodec, OpenColorIO,
   OpenImageIO, libtiff). At install time vcpkg's applocal pass copies
   these into <prefix>/bin/. At build time nothing does — build/bin/
   has only xstudio's own outputs.

This PR completes the migration started by the 1.2.0 build-system
changes and points the dev launcher at vcpkg's bin/ so plugin deps
resolve at load time.

Describe what you have tested and on which operating system.

Tested on Windows 10 Pro x64 with Visual Studio 2022 (MSVC v14.44.x),
Qt 6.5.3 (msvc2019_64), vcpkg, Ninja generator (preset
WinNinjaReleaseLocal):

• Clean rebuild from empty build/: cmake configure + ninja build succeed.
• build\run_xstudio.bat launches xstudio fully; main window opens.
• No LoadLibrary "module could not be found" warnings in the log.
• No ERROR::FREETYPE: Failed to load font crash.
• cmake --build build --target package succeeds; the staged install
  tree at _CPack_Packages/.../xSTUDIO-1.2.0-win64/ and the generated
  installer .exe contain the same files at the same paths as before
  this PR.

macOS and Linux: not retested as those code paths are unchanged. All
new branches are guarded with if(WIN32) (or are inside existing
if(WIN32) blocks). The macOS bundle assembly and Linux build/bin/
layouts are byte-identical to current develop.

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

1. cmake/macros.cmake:

   • add_resource: Windows branch copies to share/xstudio/${resource_type}/.
   • add_font: Windows branch copies to share/xstudio/fonts/.
   • default_plugin_options: Windows uses RUNTIME_OUTPUT_DIRECTORY
     for the plugin .dll, landing it directly at
     share/xstudio/plugin/. The previous POST_BUILD copy in
     create_plugin_with_alias is now redundant and removed.
   • add_python_plugin: Windows branch copies plugin dir to
     share/xstudio/plugin-python/.

2. extern/quickfuture/CMakeLists.txt: Windows branches for the .dll
RUNTIME_OUTPUT_DIRECTORY and the QML_DEST_DIR, both targeting
   share/xstudio/plugin/qml/QuickFuture/. (QuickFuture's qmldir
   declares plugin quickfuture, so the .dll must co-locate with
   qmldir.)

3. extern/quickpromise/CMakeLists.txt: Windows branch for
   QML_DEST_DIR to share/xstudio/plugin/qml/QuickPromise/. The
   .dll location is left as-is — qmldir is pure-QML with no plugin
   directive.

4. share/snippets/CMakeLists.txt: add_snip macro chooses
   share/xstudio/snippets/ on Windows.

5. src/launch/xstudio/src/run_xstudio.bat.in: vcpkg's bin/ prepended
   to PATH (between Qt's bin and %~dp0bin).

6. src/launch/xstudio/src/CMakeLists.txt: expose _vcpkg_bin_dir to
   configure_file for use in the launcher bat.

7. src/plugin_manager/test/CMakeLists.txt: drive-by cleanup — removed
   a stranded set_target_properties(${name} PROPERTIES LIBRARY_OUTPUT_DIRECTORY ...) where ${name} was undefined in
   this file (silent no-op, copy-paste leftover).

• Every change is inside an if(WIN32) block or an elseif(WIN32) branch.
• macOS/Linux behavior is byte-identical to develop.
• The install(...) rules are also unchanged on every platform, so the packaged installer is byte-identical to before (verified via --target package diff).