Implement #1611 - provide dynamic debug config

[rkeithhill]

PR Summary

This an overdue, first-pass attempt at implementing dynamic debug configurations as suggested by @isidorn in #1611. I'm completely open to changing the text that appears in the various prompts. I'm also open to the idea that "Attach to PowerShell Host Process" is rare enough that we could eliminate one level of prompting and only allow dynamic debug config for "Launch". Or maybe we make the second level quick pick a multi-select option and then create the debug configs the user selects? Then we could remove the first quick pick prompt.

BTW this functionality only comes into play when you don't have a launch.json file. The first time you configure launch.json is where you will see this. Once launch.json exists, you are always choosing from the list of debug config snippets we provide in our package.json file. One benefit of this approach is that when a user goes through this process now, they get just one debug config added to their new launch.json as opposed to everything we used to define in our package.json's initialDebugConfigurations - which was a lot of stuff.

@isidorn I tried all the other debuggers on my system in this mode and none of them prompt (node, chrome, C++ gdb/Windows, .NET Core). Are you sure this is OK for PowerShell to do? Also, would you mind reviewing this PR?

Here is what this process looks like:

Finally, I removed the temp integrated console debug config snippet. That will still continue to work but I think we should remove this for now as its a bug factory. Also, looking at this list of snippets, I wonder if we could cull it further:

I'm fuzzy on what the difference is between PowerShell: Interactive Session and PowerShell: Attach Interactive Session. Also, not sure the w/Args is worth having as a snippet. I did add to the docs on args that you could specify ${command:SpecifyScriptArgs} to be prompted for args. Thoughts?

Also, one last thing. We had the breakpoints configuration in a part of package.json that isn't valid anymore / deprecated. So, I moved it to where the VSCode debug docs say it should go. That said, I'm not sure when that switchover happened.

PR Checklist

Note: Tick the boxes below that apply to this pull request by putting an x between the square brackets.
Please mark anything not applicable to this PR NA.

• PR has a meaningful title
• Summarized changes
• PR has tests
• This PR is ready to merge and is not work in progress
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready

[rkeithhill]

This last commit reduces the number of prompts to one:

Still open to wording changes. I updated the wording of the Launch Script debug configuration snippet to show how you can invoke arbitrary commands like Invoke-Pester e.g.:

        {
            "name": "PowerShell: Launch Script",
            "type": "PowerShell",
            "request": "launch",
            "script": "enter path or command to execute e.g.: ${workspaceFolder}/src/foo.ps1 or Invoke-Pester",
            "cwd": "${workspaceFolder}"
        }

Given the above and the fact that you can use code lens to debug Pester tests (the most common way to debug Pester tests IMO), I've removed the Launch Pester Tests debug config snippet leaving these:

I'd even like to get rid of the w/args snippet. When a user gets intellisense on the args parameter they see how they can make their debug configuration prompt for args:

Plus this prompt functionality applies to both Launch Current File as well as Launch Script so it's a bit weird only having this snippet for one and not the other. Thoughts?

[TylerLeonhardt]

This looks amazing.

[rkeithhill]

That last commit whittles the debug configuration snippets to just these:

[rkeithhill]

@rjmholt Are you OK with the latest changes?

[isidorn]

@rkeithhill I appologise for not reviewing - I was out on vacation for 3 weeks.
Though I see this is merged and it looks good.
If you roll it out in insiders you should get immediate user feedback to potentially further polish this.

Thanks!

[rkeithhill]

@isidorn No worries. I'm pretty happy with where we ended up. And we can always course-correct based on user feedback.