Prevent race condition on initial breakpoints from DAP

[rsubtil]

When investigating debugging issues being reported on godot-vscode-plugin, I've encountered a race condition regarding initial breakpoints. As far as I can tell, there were no reported issues here on godot and godot-vscode-plugin regarding this.

The DAP implementation assumes all configuration is done before launching the debuggee. Particularly, that breakpoints are set before launching the project. However, that's not the case in, for instance, VSCode, which seems to set breakpoints after requesting DAP to launch a process. Initially I thought this was their issue, but microsoft/vscode#4902, microsoft/vscode#4567 and microsoft/vscode#4902 (comment) seem to suggest we cannot rely on clients to adhere to a specific ordering.

This causes a race condition that happened reliably on a Windows machine: setting a breakpoint on a _ready function did not trigger at all, since this information was not sent to the launched Godot instance on CLI (e.g. --breakpoints res://Button.gd:6), and by the point the Godot editor communicated these breakpoints at runtime, it was too late.

I'm still confused about this whole ordeal and whether the reasoning in the linked comments is actually correct, but one thing we can actually do to adress this is to wait for a configurationDone request that signals the end of configuration before launching the debuggee. This is also the solution implemented for vscode-mock-debug, and so this change essentially defers the launch request to when we receive the configurationDone request.

This comes with the implication that if a DAP client that does not support/send a configurationDone request, then Godot will remain stuck waiting for it. However, this request was added very early on v1.2.x, so I believe this scenario is extremely unlikely.

[akien-mga]

Neither me nor @Faless are very familiar with this code, but we trust @rsubtil's assessment as the maintainer of DAP.

[akien-mga]

Thanks!

[akien-mga]

Cherry-picked for 4.2.2.