Describe the bug

When the initial implementation of #3292 is merged, when there is test output, it can cause the progress bar remain on the screen, because we did not delete it when writing output.

This can also happen when test controller writes to console, because we need to write "delete progress" before any line is output.

In process we can "block" user console writes to synchronize this. But with 2 processes we could only move to the "parent" process, which is not following the current architecture.

In this output the progress should not remain on screen, but we are seeing output from 2 different processes, the testhost writing the progress, and the testhost controller writing the Slowest 10 tests.

When the Slowest 10 tests text reaches the screen, we do not issue ansi codes for "clear progress" (go up one line and delete line), because we cannot be aware of it (it comes from a different process). Console writes it, and then we emit clear progress, because the process still thinks the progress bar is the last line, which deletes 1 line of the testhost controller output (there are only 9 lines for slowest tests visible).

Unless we block all the output, or fully sync the output from the 2 processes we cannot avoid this. This is a problem common to other implementations as well, e.g. here the modern progress bar in Powershell, where we can see the same problem by writing to the console from a different thread while progress is reported:

 start-threadjob { 1..100 | % { start-sleep -Milliseconds 30 ; [console]::writeLine("aaargh $_")}}; ForEach ($Item in $Collection) {
    Write-Progress -PercentComplete ($Item/100*100) -Status "Processing Items" -Activity "Item $item of 100"
    Start-Sleep -Milliseconds 50
}

We can mitigate this problem in process by wrapping the standard Console.Out with a TextWriter that calls the clear progress callback before user outputs to screen.

Steps To Reproduce

Have a test or test controller that writes to screen while there is progress bar.