move "printCalls" + "showDevDebugOutput" to extension settings

[GitMensch]

Background: Those settings actually doesn't have anything with the actual launch configuration, where we currently need to set it. It "kind of" pollutes this, but the main issue is that it isn't possible to de-/activate it during a debug run (often I'm only interested in this output for a very special part of the code).

I volunteer to do this.

Plan:

• add settings with those two options (when we're at it I'd also add "default gdb path", which has the default of "gdb" [the actual override for a config is reasonable so it would stay])
• Option 1) clean but breaking [still my favorite]:
  • remove "printCalls" + "showDevDebugOutput" from launch config
  • use the setting variables instead of the current variables
• Option 2) full backward but also more code:
  • deprecate those launch config settings
  • read the settings when this a launch/attach/connect is done and put them into a copy of the settings
  • override the entries by the launch config
  • when settings are changed automatically adjust the copy of the settings

Optionally: move the partial available "constant boolean log" from "changeable by code only" to a setting, too - so users may activate it on request (and developers can also toggle it during run [we can later also add debug levels/groups/... but for now this optional suggestion is just to move the constant to an adjustable setting])

@WebFreak001 please advise.

[WebFreak001]

ok, you can observe for settings changes in the extension frontend, but I don't know if it's possible to send custom packets to the debug adapter.

[GitMensch]

Thanks for the possibility to go with option 1. Note. that is not about custom packages, but effectively to run-time toggle the option used in MI2.sendRaw() (only place where printCalls is used) and MI2.onOutput() (only place for showDevDebugOutput).

I'll likely work on this very soon (when I do use the "create a branch for this issue" feature the first time...), could you please review the current PRs in the meantime? Really helpful would also be someone tackling #305 including info about how to debug the debug extension (I only use log to stderr so far, which is quite a pain).

[GitMensch]

I now see what you've meant. For this issue and other's we need a communication between frontend and backend. I'm creating a new issue for that.