provide debug config variables instead of unconditional args injection

[connectdotz]

we have been injecting test name and test file arguments from the DebugConfigurationProvider, judging from #675, some users using angular frameworks are not able to debug with the extension. (the angular jest builder not able to handle the file-name argument, and in the future might only accept hyphened CLI option instead of the camel-case).

We could certainly provide more settings to allow users customizing this behavior, but thinking how many variations there could be out there, I am wondering maybe it is best to provide "variables" and let users inject into the debug configuration for their specific need. The variables can be resolved by either vscode (if we provide them as commands) or by the DebugConfigurationProvider, which can easily substitute during resolveDebugConfiguration() call.

We could maybe introduce a vscode-jest-tests@2 version of the debug config that the DebugConfigurationProvider will just look to resolve these variables (e.g. jest.currentTestName, jest.currentFileName or jest.currentFileNamePattern) instead of automatically inject test name and file arguments as it did for the current ``vscode-jest-tests` config. This change will be completely backward compatible and pretty easy to implement.

example debug config:

{
    "type": "node",ode",
    "name": "vscode-jest-tests@2",
    "request": "launch",
    "program": "${workspaceFolder}/node_modules/.bin/jest",
    "args": [
      "--run-in-band",
      "--watch-all=false"
      "--test-name-pattern",
      "${jest.currentTestName}",
      "--test-path-pattern",
      "${jest.currentFileNamePattern}",
    ],
    "cwd": "${workspaceFolder}",
    "console": "integratedTerminal",
    "internalConsoleOptions": "neverOpen",
    "disableOptimisticBPs": true,
    "windows": {
       "program": "${workspaceFolder}/node_modules/jest/bin/jest"
    }
}

@orta @stephtr @michaeljota what do you guys think?

[stephtr]

To me that sounds like a good idea!