Avoid locking all threads on debugger suspension

[st0012]

This commit stops locking all threads during suspension, which may prevent users from investigating threading problem. But it's still better than freezing the process just by running a ActiveRecord query, or doing anything that calls Timeout.timeout.

History around this issue:

1. It originally was reported in https://github.com/Shopify/ruby-dev-exp-issues/issues/724, and we reported it upstream too.
2. We introduced 1e0f45c as a workaround.
3. Upstream proposed a solution to fix the query evaluation case by restarting threads before evaluating console/DAP input. So the above commit was reverted.
4. However, the process could still hang if Timeout.timeout is called: 1. During a suspension 2. And outside of input evaluation An example is typing Arrow-up in the console as reline calls Timeout.timeout underneath.
5. So we need to reintroduce the workaround until we can find a better with the upstream maintainer.

[vinistock]

Is anything lost by not stopping all threads? Or in other words, why isn't this the optimal solution?

[st0012]

Yes it has some drawbacks:

• In multi-thread scenario, we'll see the same messed up output when a breakpoint is hit by multiple threads. This is the same problem you'd see with Pry or IRB, for example.
• Because debug assumes all threads are always stopped, there's no command to stop/unstop individual threads. This means with this patch, we don't have the ability to control individual threads and they'll always be running.

But since multi-thread support to us is not a significant, it's a tradeoff we can happily take to fix the serious issue.

That being said, I also asked if it's possible to make thread stopping configurable. And perhaps when configured as "not stopping threads by default", we can have commands to control individual threads.