This is especially helpful for tests that don't have code locations.
The user can run a subset of tests
and changes to that portion of the
test tree will be reflected

Refactored state updates around individual projects.
This reduces mapping since tests execution is actualized by project

This is a preperatory refactor in anticipation of changing
test discovery from trx to --list-tests

I.e. when there are mixed + and . separators in the test name

The previous filter found all known test items to run from the explorer
and matched them exactly.
But this won't allow the explorer to discover tests from test results.
If the user selects a group of tests, then it should run all tests in
that group even if they aren't in the explorer
then updated the explorer if there are differences.
This is especially critical for C# tests which can't match code locations
and update that way.

Improves discoverability of error and failure messages,
especially for tests without code locations.

Building projects in parallel was leading to build failures
and tests being discovered incorrectly.
Also effected explorer refresh.

Restoring in parallel was spawning too many promises (i.e. 87 in FAKE solution)
and causing computer lag

Added a new method that runs at most a certain number of Promises at a time.
Allows a balance of resource usage safety and speed.

It's faster than sequential, but know we won't end up queuing so many
promises we end up with resource starvation.
I.e. restoring against 87 projects in the FAKE repo

take and skip are unsafe operations, causing executeWithMaxParallel
to error if the input collection is smaller than the max parallel count

This fixes indeterminism if a project has multiple target frameworks.
Especially if it runs some tests only on certain targets.

Always using the first target framework aligns with other Ionide behavior.

The top level of the test explorer is organized by project.
This will simplify some efforts like progressive loading
and supporting multiple Target Frameworks

Paves the way for multiple Target frameworks
and provides context so users can figure out why the test count is
different than the console or other test explorers

See this discussion: ionide#1874 (comment)

Trailing spaces were causing test run results to not match up with
the expected test items.

The same issue still exists for leading spaces in a test name.
However, It's unclear how consistent the indentation of test names
would be in the console output.
Rather than increase the risk of failure,
I opted to retain the potential error for leading spaces.
Leading spaces in a test name should not be common use case and is most likely an mistype

Moving responsibility for initial restore to the user.
It was proving difficult to consistently report restore errors,
and, since we don't have access to optimal build orders,
restore was adding a lot of time to test discovery
when we nominally expect it to already be done.

Detect build failures and when a test run likely failed to complete

Prevents performance issues experienced with a large number of test projects.

Parallel project builds can conflict if they have mutual dependencies.
This was more prominent during discovery and already fixed there,
but it can also happen when running tests.

Linearizing the build and limiting parallelism also changed the test status UX.
Explicitly showing all enqueued right away makes it more intuitive that
that the explorer responded correctly to the user's run request

Pass cancel tokens through the test, build, and refresh call chains.
Attempt to kill any long-running processes spawned
(i.e. dotnet test, msbuild)

Unfortunately, secondary processes (like testhost)
aren't cancelling when their parent does.

Used to for workarounds specific to NUnit.

NUnit can't handle spaces in test filter expressions.
The mitigation for it depends on knowing the test is an NUnit test.
However, that information was only available if
code-sourced test info is merged after code discovery.
This makes that info available from trx discovery too.