Task-based debug build/run

[bwateratmsft]

Resolves #1242

[philliphoff]

Ok with getting this infrastructure in now that 0.8.0 is out the door; other incremental changes are probably better off done as separate PRs at this point, as it's getting difficult to distinguish between such changes in this PR.

[ejizba]

My biggest TypeScript suggestion is to turn on strictNullChecks in tsconfig.json. This repo had plenty of code, but very little linting when we took it over. Linting comes in two forms: directly from TypeScript in tsconfig.json and through tslint in tslint.json. Without strictNullChecks, null and undefined are pretty meaningless plus a good chunk of tslint rules don't even run

This util file will be the biggest help with that: https://github.com/microsoft/vscode-docker/blob/master/src/utils/nonNull.ts

Even if you don't have the time to convert the whole repo to stictNullChecks, I would at least suggest turning it on when you add a bunch of new files and at least fixing the errors for your new files.

[ejizba]

Isn't a "dockerBuild" property redundant when the task type is already "docker-build"?

[bwateratmsft]

Here, dockerBuild is for all the options you'd pass to it, like --pull, args, etc.

[ejizba]

So this is what a few example random tasks look like:

{
	"type": "shell",
	"label": "npm lint",
	"command": "npm run lint"
},
{
	"type": "npm",
	"script": "lint",
	"problemMatcher": "$tslint5"
},

I feel like this is what yours is doing:

{
	"type": "shell",
	"shell": {
		"command": "npm run lint"
	},
	"label": "npm lint",
},
{
	"type": "npm",
	"npm": {
		"script": "lint",
	},
	"problemMatcher": "$tslint5"
},

The task inherently is the object where you put any options

[bwateratmsft]

I get that, but there's also things that don't get fed to the docker build call--like our platform-specific options (node, netCore). On the debug launch config there's also meta-options like dockerServerReadyAction; we could end up with such meta-options for these tasks too.

[ejizba]

But the platform-specific options do describe things that get fed to the docker build call, including the container name and command.

[bwateratmsft]

...but also things like the .NET Core project, which is not directly part of docker build, and in the case of docker-run whether to configure SSL or not, which does a host things--volumes, commands run on the host, changes to the project file itself...

[ejizba]

Per Steven's comment, I'd prefer to see unit tests for this kind of difficult-to-understand logic