Extending linux-thread-db to support user space threads

Hi,

As nothing seemed to come from Tom Tromey's work on supporting green 
threads (https://sourceware.org/pipermail/gdb/2022-March/049959.html), I 
decided to try extending linux-thread-db to support more than one GDB 
thread per LWP. You can find my efforts so far at:

https://github.com/ned14/binutils-gdb/commit/e86072ff6d3c12c97e846baa99f5157cdd9b17fc

I have taken a different approach to Tom, who added an additional thread 
backend which had Python scripting tell GDB about the green threads. 
Instead, mine relies on the GDB user supplying a custom 
`libthread_db.so.1` which overlays on top of the NPTL `libthread_db.so` 
to additionally supply what userspace threads there are. If 
linux-thread-db finds system threads being returned by 
`libthread_db.so.1`, it'll then additionally ask `td_ta_thr_iter()` for 
threads with state `TD_THR_RUN` (i.e. user space threads only) whenever 
the list of threads needs updating.

If all this sounds a bit complicated, there is a test case in the commit 
above which compiles a test `libthread_db.so` wrapper and shows the 
concept in action.


Where I'm a bit stuck is how to implement thread switching into these 
user space threads. `td_thr_get_info()` does supply the stack pointer 
and program counter at the point of user thread suspension, plus bounds 
for the stack. There is, therefore, sufficient information for GDB to 
print a backtrace. You obviously could not resume such a thread as when 
it runs is under userspace control, but being able to see where it has 
suspended and what it was doing up to the point of suspension would be 
invaluable.

If somebody more knowledgeable of GDB internals could give me a few 
pointers on how best to implement this, I would appreciate it.

Also, if you think that there is a way of going about this to make it 
more likely that this patchset be accepted into GDB in the future, I 
would be interested in hearing more.

My thanks in advance.

Niall