Option to create msbuild-tools.json

[gwicksted]

At the very least place the contents of the json example from the readme into a file in the correct location on disk via CTRL+SHIFT+P option. Might also trigger this action if the user attempts a build without the file created.

This saves a step of finding the plugin in the marketplace again and copy-and-pasting the json example into a new file.

Quite a bit more work is attempting to detect the correct settings. Here are my thoughts on the latter:

• Detect the VS install path (much harder with VS2017) by trying a few paths. Where you currently have "Community" it could also be "Professional" or "BuildTools". (maybe "Enterprise"? I don't have a copy to test with) Make sure you attempt "BuildTools" last since it does not have the IDE and they can be side-by-side installed.

• Locate the .sln file within the workspace and fill in "solution" relative to ${workspaceRoot}

• If there is a folder with the same name as the .sln file (without the extension) and it contains a .vcxproj, assume that it must be included in the "debugConfigurations" "program" path.

• Look for both "${buildConfig}" (Debug/Release) and processor architecture ("x64/x86") to compute the (default) output paths where the executable will reside. You could look for already created paths on disk but they may not exist yet if it hasn't been built.

• Alternatively, targets can be obtained from the .sln by parsing the following lines:

Global
	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug|x64 = Debug|x64
		Debug|x86 = Debug|x86
		MyCustomConfig|x64 = MyCustomConfig|x64
		MyCustomConfig|x86 = MyCustomConfig|x86
		Release|x64 = Release|x64
		Release|x86 = Release|x86
	EndGlobalSection

• You might be able to obtain some additional information by invoking msbuild /pp (which evaluates the project file and inlines all included files and writes them to stdout).