Attach debugger to running R sessions

[ManuelHentschel]

Current situation:
The debugger always starts a new R process for each debug session and has direct access to its stdin/stdout/stderr.

This is ideal to make the debugger as powerful as possible, but can be a problem when users want to e.g. view the variables in an externally running R process or need more direct access to the stdio of the process.

Intended improvement:
Add an "attached" debug mode, where the debug adapter is started from within a running R session and handles DAP-messages received through a tcp socket. When disconnecting from the debug adapter, the R session resumes and can be controlled via stdio again.

WIP:
The branches VSCode-R-Debugger/attach and vscDebugger/attach include basic support for attach requests. To use this mode, start an R session and run the command vscDebugger::.vsc.listenForDAP().

Then launch the debug config entry

        {
            "type": "R2-Debugger",
            "request": "attach",
            "name": "Attach to R process"
        }

to start debugging. Use continue/disconnect to return control to the stdio of the R process.

Open questions:

• (Update see below) I'm still unsure whether/how to include flow control in this debug mode. For R processes that are launched outside VS Code, this appears to be rather difficult if not impossible. For R processes launched by VS Code it might be possible to implement the custom requests used to send text to stdin in order to control program flow:
  

  VSCode-R-Debugger/src/debugProtocolModifications.ts

  Lines 155 to 168 in 1862d8e

  	export interface WriteToStdinBody {
  	reason: "writeToStdin";
  	text: string;
  	when?: "now"|"browserPrompt"|"topLevelPrompt"|"prompt";
  	fallBackToNow?: boolean;
  	addNewLine?: boolean; //=false (in vscode), =true (in R)
  	count?: number; // =1
  	stack?: boolean;
  	// info used to identify the correct terminal:
  	terminalId?: string;
  	useActiveTerminal?: boolean;
  	pid?: number;
  	ppid?: number;
  	}

• Using task callbacks might be useful to update the variable view on each step (but is limited by the "interactive" nature of the DAP, which requires the R process to be listening on the tcp port in order to e.g. expand the entries of a list).
• Launching in this mode might be useful
• Attaching to R processes running in VS Code's integrated terminals might interfere with the features from https://github.com/Ikuyadeu/vscode-R/
• ...

[ManuelHentschel]

Update:

The last changes add basic flow control for attached R processes that run in integrated terminals. In order to send commands (n, c, ...) to R's stdin, the WriteToStdinEvents mentioned above are sent to a different port and handled in the vscode extension.

In order to send the commands to the correct terminal, these events now include the pid of the R process, the pid of R's parent process (only works on unix like systems), and the value of the environment variable VSCODE_R_DEBUGGER_TERMINAL_ID (fallback for non unix like systems, i.e. windows), which is set by the following vscode setting and updated after a terminal is created.

    "terminal.integrated.env.windows": {
        "VSCODE_R_DEBUGGER_TERMINAL_ID": "1"
    }