NuGet and self-testing gotcha

This one took me quite a while to unpick.

• Scenario - you have a global tool which includes dotnet test integration. As part of build validation, the nuget package (either newly minted, or an existing release) is invoked when running the unit tests.
• Problem - actually the dotnet test integration is ignored.
• What seems to happen - if the main executable is linked from the dotnet unit test assembly, nuget doesn't restore the package.
• Bodge - turn the dotnet unit test assembly into a shim that simply invokes the actual tests in another assembly, dotnet test against the former, and run the .Net tests on the test assembly. This is where things stood for the last few years.
• Resolution - turn the actual tool executable into a complete shim that simply invokes the actual logic in another assembly, and don't unit test that trivial method. Then the dotnet and .Net framework tests can build from the same project.

I had almost completely done that for AltCover, but there was one little bit of logic left in the entry-point method to test, a residue of the old three-way split between .Net framework, old-style netcoreapp2.0 command-line tool (now obsolete), and the new netcoreapp2.1+ global tool, for some global tool only behaviour, the logic included or not by compile time flags based on target framework. That one piece of logic, for the TargetsPath global tool parameter has now been pushed down into the central netstandard2.0 assembly ("Engine"), with a target framework dependent compile-time boolean flag being passed to it from the entry-point shim instead.