Give the host-side kill of a WSL tool time to finish

[SimonCropp]

Fixes the failed build of main at ad076ab (#952), where two jobs failed.

wsl 1: the kill timed out

WslLiveTests.AStartedToolIsFoundByItsCommandAndEndedOnTheHost failed because WslInterop.Kill returned false. The kill runs Windows PowerShell on the host through WslHost.Run, which gave up after five seconds, and the test took 6.9. On a build agent a cold PowerShell is several seconds slower than on a developer machine: the same class took about four seconds there against 1.3 locally, so five was marginal.

That is a product problem as well as a test one, since a slow or cold machine left a user's tool open the same way.

• The kill has its own wait of thirty seconds. It is only spent where a window is there to close.
• The script asks Windows for the tool's processes by image, rather than for every process with its command line. Measured locally this is a small gain, about 30 ms of 310; most of the time is PowerShell starting.

windows: a timing test stalled

ViewerProtocolTests.AnUnresponsiveOwnerTimesOutRatherThanHanging expects a one second timeout to return within fifteen and took twenty one. It did not reproduce in four local runs limited to two processors, and the same suite had passed on the three runs before.

A possible contributor, not proven: WslKillScriptTests held a thread pool thread for as long as each of its four PowerShell runs took, which on an agent is seconds. They now read PowerShell's output asynchronously and poll for the stand-in's exit, so no thread is held. They also take PowerShell's error stream, which was writing its first-run progress into the test log.

Checked

• The WSL test classes pass on Windows on .NET 10 and .NET Framework 4.8.
• Inside an Ubuntu distribution under WSL 2: the live tests pass three runs in a row, and P4Merge and WinMerge opened from a failing test still close when it passes.
• Not checked: WSL 1, which is where the failure was. The wsl 1 job on this PR is the check.