Fixes microsoft/vstest#2570 by moving _ComputeTargetFrameworkItems outside the CallTargets used inside the VSTest target. This means that @(_InnerBuildProjects) is available in all CallTarget scopes.

What happened in a tiny sample project with a multitargeted library and a test assembly that @dsplaisted used was this:

1. The VSTest target runs in the library, creating a CallTarget scope.
2. Inside that scope, BuildProject runs, creating a CallTarget scope.
3. Inside that scope, _ComputeTargetFrameworkItems runs, populating @(_InnerBuildProjects).
4. Inside that scope again, the inner builds are dispatched to and built.
5. The VSTest target runs in the test project, and eventually calls down to the normal build process.
6. That process calls GetTargetFrameworks on the library project.
7. The library project sees that _ComputeTargetFrameworkItems has already run and skips it.
8. The library project proceeds to GetTargetFrameworksWithPlatformFromInnerBuilds, but doesn't have access to @(_InnerBuildProjects) because it's trapped in a scope, so the dispatch fails.
9. The test project then tries to directly reference the outer build of the library, which has no primary output.
10. The compiler fails because the library wasn't passed to it.

Step 8 is what's new. That was computed before dotnet/msbuild#5657 with only evaluation-time data, but now requires multitargeting dispatch.

Ideally, we'll eliminate CallTarget entirely. At this late time, however, this is a safer choice: ensure that @(_InnerBuildProjects) is populated in the biggest possible scope before any of the VSTest machinery runs by depending on it from VSTest.