fix: use PowerShell to parse PowerShell

[bolinfest]

Previous to this PR, we used a hand-rolled PowerShell parser in windows_safe_commands.rs to take a &str of PowerShell script see if it is equivalent to a list of execvp(3) invocations, and if so, we then test each using is_safe_powershell_command() to determine if the overall command is safe:

codex/codex-rs/core/src/command_safety/windows_safe_commands.rs

Lines 89 to 98 in 6e6338a

	/// Tokenizes an inline PowerShell script and delegates to the command splitter.
	/// Examples of when this is called: pwsh.exe -Command '<script>' or pwsh.exe -Command:<script>
	fn parse_powershell_script(script: &str) -> Option<Vec<Vec<String>>> {
	let tokens = shlex_split(script)?;
	split_into_commands(tokens)
	}
	/// Splits tokens into pipeline segments while ensuring no unsafe separators slip through.
	/// e.g. Get-ChildItem | Measure-Object -> [['Get-ChildItem'], ['Measure-Object']]
	fn split_into_commands(tokens: Vec<String>) -> Option<Vec<Vec<String>>> {

Unfortunately, our PowerShell parser did not recognize @(...) as a special construct, so it was treated as an ordinary token. This meant that the following would erroneously be considered "safe:"

ls @(calc.exe)

The fix introduced in this PR is to do something comparable what we do for Bash/Zsh, which is to use a "proper" parser to derive the list of execvp(3) calls. For Bash/Zsh, we rely on https://crates.io/crates/tree-sitter-bash, but there does not appear to be a crate of comparable quality for parsing PowerShell statically (https://github.com/airbus-cert/tree-sitter-powershell/ is the best thing I found).

Instead, in this PR, we use a PowerShell script to parse the input PowerShell program to produce the AST.

[pakrym-oai]

should we use shell detection here?