Enable running example tests massively in parallel via dotnet test or UI

[jnm2]

dotnet test tools/ExampleTester now runs and produces the same output as dotnet run tools/ExampleTester (which still works), except that it will parallelize the tests and finish in a fraction of the time that Program.Main takes.

You can also click and run a given example in the UI of any .NET test runner, and see red and green states, and see output per test, add a few examples to a test session/playlist for repeated runs, etc. ...these are just standard unit tests.

I've noticed that the GitHub checks are all pretty fast except this one which takes about 9 minutes. We may want to consider switching over the GitHub Actions job to invoke the tests the new way. Even if the build server doesn't parallelize particularly well, simply overlapping the various stages of each test should produce benefits. (Loading csproj, getting compilation, getting diagnostics, emitting, running output.)

[jnm2]

I could not figure out a way to get xUnit to parallelize between individual cases within a theory. Also, the Visual Studio Test Explorer UI for an xUnit theory does not show theory cases as individual nested tests, so they can't be individually run or added to playlists. NUnit shines in this area.

[jnm2]

💭 We could consider having these tests read directly from the standard without going through the ExampleExtractor step. That could confer a few benefits such as possibly removing the use of the very slow MSBuildWorkspace, keeping cached Roslyn compilations around in memory that match each project template. This could result in very fast tests. The downside would be that you wouldn't be able to open the .csproj files in an IDE to play around with things, if there is no tmp folder.

Edit: I was able to get the very fast runs without disrupting the flow via .csproj files on disk: #1338

[BillWagner]

This LGTM.

I'll also ping @jskeet for review offline. I think we can merge and update this without spending committee time.

[jnm2]

@jskeet Would you be willing to take a look?

[jskeet]

Yup, I'll look tomorrow.

[jskeet]

Still coldy, but yes, I don't see problems with this so long as we still actually get consistent results :)

(We're generating everything into separate directories, so parallelizing that part should be fine - and if I understand correctly the actual execution is serial, so that shouldn't interfere.)