Fix cargo runner execution error on Windows when workspace path contains spaces (Enhances compatibility with VS Code forks)

[2bitbit]

Description:
When using CodeLLDB to debug a Rust project on Windows, if the user's profile path (or extension installation path) contains a space (e.g., C:\Users\Xie bro\...), launching the debugger via the default Cargo task fails with os error 193 or os error 2.

Note: While vanilla VS Code sometimes masks this issue due to its specific internal task argument escaping, this bug consistently triggers fatal crashes in VS Code forks and derivatives (such as Cursor, Antigravity, etc.) when handling paths with spaces.

Root Cause:
In extension/cargo.ts, the cargo runner is currently injected as a raw string:
--config=target.'cfg(all())'.runner='${launcher}'
When Cargo parses this configuration, it splits the unescaped string by spaces. This causes Windows to incorrectly interpret the first half of the path as the executable (e.g., trying to run C:\Users\Xie) and the rest of the path as arguments, immediately crashing the launch process.

Solution:
Changed the injected runner configuration to use the standard TOML array format and replaced backslashes with forward slashes to prevent any escape sequence corruption during CLI handoffs:
--config=target.'cfg(all())'.runner=["${launcher.replace(/\\/g, '/')}"]

By passing the path as a TOML array ["..."], Cargo strictly interprets the entire path as a single executable, regardless of spaces. Tested locally and this perfectly resolves the startup crash, ensuring robust compatibility across all VS Code-based IDEs.

[vadimcn]

Implemented in v1.12.2, but a bit differently.