VSSDK projects shouldn't extract to experimental instance when running unit tests

[drewnoakes]

If a VSIX project is in the reference graph of a unit test project, then it will be built whenever a user runs unit tests.

In a repo I'm working in, we don't want to deploy when building for unit tests.

1. The deploy isn't very fast. It adds delay when you're waiting for unit test results.

2. If the experimental instance is running, the deploy fails because the destination files are in use. This fails the build, which means tests don't run. You have to kill the experimental instance, which feels like an unnecessary interference to your workflow.

   1>D:\NuGetPackages\microsoft.vssdk.buildtools\17.12.2084-preview3-gea5fc75f5e\tools\VSSDK\Microsoft.VsSDK.targets(987,5): error VSSDK1081: Problem occurred while extracting the vsix to the experimental extensions path. The process cannot access the file '%LOCALAPPDATA%\Microsoft\VisualStudio\17.0_c0707f09Exp\Extensions\Microsoft Corporation<package><version><assembly>.dll' because it is being used by another process.

I wonder if it's every helpful to deploy when running unit tests in the VS test runner. If not, then we can disable this step during build. We currently identify "indirect" builds (those which happen for unit tests and for debug launches) via a global property. We could use a similar mechanism in the project system to convey to the VSSDK targets that we're just running unit tests.

It's unclear if this is safe to do. At the least, it'd be good to have a way to opt in to this behaviour. Perhaps we add a project property page for VSSDK projects that has a checkbox for this.