Currently, the runInTerminal is implemented by using --wait-for underneath, which is error prone as it often can't attach on Linux. A reason I've found is that LLDB does process polling by using commands like "ps", which are not standard across distributions. This is a problem that doesn't happen on Mac.
For more context, the debug adapter protocol specifies that the response of the "runInTerminal" reverse request doesn't need to provide the pid of the process launched by the IDE. VSCode, for example, doesn't return the pid. Without this pid, the only way to attach to the process is with --wait-for.
However, IDEs like VSCode support customizations of their debuggers, allowing it to return the pid. In this case, lldb-vscode needs to know that the IDE will return the pid and therefore it shouldn't use --wait-for. Because of this, lldb-vscode will also require the launch request to include 'runInTerminalRespondsWithPid: true' to work this way. This is acceptable, as the user/developer is already customizing the IDE, so doings the pid addition and the runInTerminalRespondsWithPid inclusion are simple changes.
This new approach to runInTerminal is guaranteed to attach to the process, as long as it doesn't finish right away, which is better than what we had before.
Tested on Mac and Linux