Support stop reasons for multiple threads (with one flagged as current) in a single stopped event

[polinasok]

In highly concurrent languages it is possible to hit multiple breakpoints at the same time (or hit a breakpoint while responding to a user halt request). For example, see dlv documentation and related golang/vscode-go#130.

Currently the only way to support reporting of multiple breakpoints is to send multiple stopped events. There are a couple of issues with this (besides the obvious extra redundant traffic from multiple stopped events):

1. At least in vscode, the events must be issued in a specific order to achieve the desired UI effect. The ordering interactions are not obvious from the protocol. For example, the current thread must be the one with the stopped event sent last, so that's the thread that gets its variables reflected in the UI. And AllThreadsStopped field must be set only in the first stopped event we send, or it will overwrite the specific reasons from the additional stopped events with the default "paused".
2. Each stopped event triggers a threads request. And while the subsequent stackTrace requests are thread-specific, the threads requests are the same every time and can be quite expensive. See related issues: Please suppress duplicate threads requests vscode#110927, Paging support for threads #159).

[polinasok]

We came across another case where want to set stopped reasons on threads other than the one specified via StoppedEvent.body.threadId. In Go, there are cases where execution doesn't cleanly stop in the user code, so there is no valid user thread id to specify in the stopped event with a stop reason. The way vscode interprets the protocol results in the stop reason not showing up at all in the UI because it is always attributed to a specified valid thread (see microsoft/vscode#124532). But we still need to communicate the stop reason for the rest of the threads (since execution always stops for all) even if we have no ThreadId to set. This might be the exact same stop reason for all or different reasons for different threads if multiple stop conditions happened at the same time.

Therefore, it would be great if we could specify the following:

• [already supported] threadId + stopReason - highlights the thread -- triggers stackTrace and other waterfall requests
• [new] default stopReason for all threads not explicitly specified by id when allThreadsStopped is set
• [new] per-thread stopReason for additional threads -- these won't be expanded and won't trigger waterfall requests by default, but would only communicate more nuanced reasons than the default