Additioanl DEBUG tasks or features - commands to run.

Feature Request

In my case, I cross compile to an embedded target for RISCV and CortexM3 it varies greatly.

would like to have the ability to have some extra commands in the VSCODE launch window? Or maybe these belong somewhere else - I am not sure.

Generically, the json configuration file that I think would work is as follows:
I'll describe each of these below in more detail
But in general, the tags are:

 "Background" 
  If FALSE this means it just runs and it is done rather quickly.
  If TRUE, this means it might run during/ or in the background of a debug session.

Example: We used networked power supplies, I have a python script that can control power

"command" and "args" - is the command to run and parameters

          Each command should run in a console window of some type.
          and if the application exits 0, then the console can close.
          If however the app exits NON zero - do not close console let me read the error message.
          PLEASE allow for ENV variables to be used here, ie: ${USER} should resolve to the username.
          Thus, I could specify the command:   "python  scriptname.py ${USER}.json"
          when Alice runs the command she would get:  "python scriptname.py alice.json"
          and if user Bob ran the command it would be: "python scriptname.py bob.json"

The "ignoreerror" is for crappy scripts that do not exit correctly, sadly they exist.

    The "background" - this is the tougher nut to crack, there are different use cases:

case 1) The DETACHED window case:

        I might for example launch the Linux version of PUTTY - which starts its own window.
        Or maybe I launch xterm running MINCOM inside the new XTERM window.
        On a windows machine, i might use PUTTY or TERATERM
        I do not want to tie up a VSCODE window or sub-window for this.

        This serial console would run continuously in the background
        I might want to watch DEBUG boot/log messages when the power is toggled 
        Or maybe my embedded target has a debug serial port for print messages.
        I do not want to tie up a VSCODE window or sub-window for this.

        VSCODE should just "detach" and let it run on its own window and be done with it right away

Case 2: The attached console window
There are 2 variants of this case:

         Case2a - this should have a console window inside VSCODE.
         The use case is I have a Python script that can control the power supply to my target.
         I can use a python script to power the target OFF or ON, or just toggle OFF then ON.
         In this case using a VSCODE console window is a great solution.
         
         Important - if the command exists with a NON-ZERO the window should not close
         This allows the user to see error messages that where printed out.

         EXAMPLE: Click a windows batch file and watch it print error messages and exits.
        
          Sadly, the "IGNORE-ERRORS" exists to handle the case where that needs to be ignored.

       Case 2b: Might be a VSCONSOLE script in some form that stays open.
     
        An example might be the script will SSH into a remote machine and launch the GDBSERVER
        In this case, it needs the ability to hit "CONTROL_C" to exit/stop/kill the script

NOTE:
About ${USER} - it would be helpful if arguments could contain ENV VARIABLES.
On linux, this can happen automatically depending on how you exec sub process.
In one case you could use backticks and ${ENV} vars, in other cases it will not.
I would prefer the ability to get ENV Vars to expand

===========

"added_commands" : {
"Toggle Power" : {
"background" : "False",
"command" : "python",
"args" : [ "power-script.py" , "10.168.99.123", "toggle" }
"ignore-error" : "True",
},
"Launch RISCV GDBSERVER on LAB102" : {
"background" : "True",
"command": "python" ,
"console" : "True",
"args" : [ "launchserver.py", "${USER}", "lab102", "riscv" ],
},
"Launch Linux Console" : {
"background" : "True",
"command" : "putty",
"args" : [ "-load", "linux_console_session" ]
}
}

Start by examining the extension's existing VS Code launch configuration and command/task entry points. Clarify the scope and configuration shape for added commands, background or detached consoles, environment-variable expansion, exit-error handling, and interruption before implementation; done means the agreed scenarios work from the VS Code launch window.