add limit to threads pane

[a-mr]

When there are many threads in the debugged program the threads pane takes up too much space. This patch introduces the limit to number of threads displayed and sets it to 8 by default.

[cyrus-and]

I'm not 100% sure about this, I see you've implemented the same semantics that the Stack module has, but unlike stack frames, there's no meaningful order in the thread list (besides thread creation).

In particular while it does make sense to only show [i, i+K] stack frames, the choice of omitting the first [0, i-1] threads sounds pretty arbitrary. In other words, the currently selected thread must surely be displayed, but what about the others? For example, one could be interested in the current thread (the last one) and the first one only.

Yet, the problem of having too many threads is real, off the top of my head I can see two solutions:

1. introduce an option to only display the current thread;

2. introduce an option to filter by regex.

Option 1 kind of nullifies the idea of having a Threads module in the first place, since the Stack pretty much shows the same information in this case. Option 2 might be maybe too cumbersome to use...

[a-mr]

Hi, you've got a good point. Actually I had in mind a case when there is one (or may be 2) primary thread(s), and multiple worker threads, so I wanted to display threads with 'minimum' numbers. And the first solution was not really well-devised.

Now a parameter 'show' is implemented instead, it gets a list of ranges, from which allowed threads are selected. E.g. one can select a set like this: '1,2,5-7,c', where 'c' means current.

This solution makes sense if those thread numbers are unique, and it seems gdb ensures this inside one given gdb session: after gdb attaches the numbers are being added after the last thread without going into the gaps of finished threads. However I have little experience in multi-threaded debugging.