Fix Windows LSP initialization error caused by backslash paths

[kjanat]

Summary

Fixes a language server initialization error on Windows where PowerShell Editor Services failed to start due to backslashes in absolute paths being misinterpreted as escape characters.

Problem

On Windows, the extension was passing absolute paths with backslashes (e.g., C:\Users\...) to PowerShell commands. PowerShell interprets backslashes as escape characters, causing errors like:

Import-Module: Cannot find drive. A drive with the name '\C' does not exist.
Start-EditorServices: The term 'Start-EditorServices' is not recognized...

Full error

Language server powershell-es:

initializing server powershell-es, id 8: Server reset the connection
-- stderr --
�[31;1mImport-Module: �[31;1mCannot find drive. A drive with the name '\C' does not exist.�[0m
�[31;1mStart-EditorServices: �[31;1mThe term 'Start-EditorServices' is not recognized as a name of a cmdlet, function, script file, or executable program.�[0m
�[31;1m�[31;1mCheck the spelling of the name, or if a path was included, verify that the path is correct and try again.�[0m

Solution

• Normalize LSP paths by converting backslashes to forward slashes before passing to PowerShell
• PowerShell accepts forward slashes on all platforms (Windows, macOS, Linux), making this a safe cross-platform solution
• Apply clippy suggestions for more idiomatic Rust code
• Update dependencies including zed_extension_api from v0.2.0 to v0.7.0

Changes

• Convert Windows backslashes to forward slashes in language_server_path() method (src/powershell.rs)
• Update extension dependencies to latest versions
• Bump extension version to 0.3.1
• Apply clippy auto-fixes for improved code quality

Testing

Tested on Windows with PowerShell 7 where the language server now initializes successfully without path-related errors.