Make pausing to set breakpoints optional

_Things I am planning to work on as part of my exploration of how to debug Indel industrial control systems with Visual Studio Code:_

In `GDBDebugSessionBase.setBreakPointsRequest` and similar methods, the adapter currently assumes that setting breakpoints requires at least one paused thread on the target. That is not true of all targets – some, such as our combination of stub and target, are capable of setting breakpoints without pausing any threads.

In fact, on industrial automation systems like ours, we absolutely must not (even temporarily) pause arbitrary threads on attaching, because that could wreak havoc on the real-time behavior of a running machine.

I therefore propose that clients can somehow tell the adapter not to do that kind of pausing, probably by an additional option in the launch/attach arguments, but I haven’t thought it through yet.

Note that this will not completely solve the problem yet, because GDB itself internally also pauses threads to set breakpoints or read memory. I have not determined yet how to solve that and whether the solution will involve the adapter.

Further notes copied from https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/pull/407#issuecomment-3118255057:
- We are only interested in non-stop mode. All-stop mode doesn’t make sense on a system where real-time-critical (e.g. motion control) threads need to continue running while you are debugging a non-real-time-critical (e.g. production sequence) issue, and also where the debug communication itself is handled by one of the threads running on the target that therefore must not be stopped.
- Thoughts on solving the GDB-internal problem: I would like to avoid patches to GDB as far as possible (we had more of them in the past). I may have to reintroduce some of the behavior we are currently using with Eclipse, where the stub “lies” to GDB and presents threads as “stopped” when they are actually not (according to what GDB considers “stopped”, i.e. “won’t continue unless I tell it to”), but just temporarily waiting on a synchronization object or descheduled because a thread of higher priority is running, so the situation that all threads are running from the point of view of GDB never occurs. But that required patches to the front-end (CDT DSF) in Eclipse, and now with Visual Studio Code I am still hoping to be able to work with an unmodified front-end.