Optimize PowerShell availability check: file existence fast path with automatic recovery

[Copilot]

Human PR description by @nagilson:

Summary

Powershell is often not found / resolved properly on machines. This happens for about 6% of our (windows) customers.
Before, we resolved which powershell path worked before we ran the install script.

Prior Code:

1. Try powershell.exe (94% success rate)
2. try full path to powershell (18% success rate, so about 95% now)
3. try pwsh (1.3% success rate, so about 96.3% now)
4. It used to try pwsh.exe which had 0% success rate, waste of time
5. same with powershell, 0%, waste
6. then run install script

Now:

We check if the file exists and run with the hard-coded powershell path without trying to verify powershell 'works' first, then fall back to checking for a working powershell and retry with that once.

file exists check median: ~0.2–1.4 ms
prior powershell.exe check median (on success): 335.1 ms
new full path exe check median ( on success): 75 ms

What this means:

1. We save 594 ms (335 ms - 1 ms for file check PLUS the 260 ms differential on using the full path invocation ) ms on windows for all .NET acquisitions per median user for ~94% (<- I don't have data on who the full path works for but the powershell.exe path does work for, so this is approximate, but in general it seems to be more reliable) of customers with this change.
2. We save 6 ms for failure cases by eliminating extra checks (failure cases median only 1-4 ms) for those 3.7% of customers without working powershell.

Considering the number of users who run this code, this means with this change we collectively save about 20 days in time worth of startup delay in VS Code, per month.

3. We'd save 335-75 (260 ms) for customers by using the full path over the .exe shell resolved path when it works but we still have to try to resolve the path. However, we just use that by default now, which also saves time on the process spawn.