Problem

In the current threading backend, `ThreadGroup.thread_done()` is never called automatically when a thread completes.
As a result, completed threads can remain in the thread group’s internal list until an explicit wait or stop occurs.

This differs from the eventlet backend behavior and can lead to unbounded growth of the thread list in long-lived services.

Root cause

`thread_done()` exists for API parity with the eventlet backend but was never wired into the thread lifecycle in the threading backend.

Solution

• Wrap the thread callback in a `try/finally` block so `thread_done(threading.current_thread())` is always invoked on thread completion (normal exit or exception).
• Update `_wait_threads()` to avoid holding the lock while joining threads, preventing potential deadlocks when `thread_done()` is called from the finishing thread.
• Add unit tests covering:

• Normal thread completion
• Thread termination via exception
• Multiple concurrent threads
• `waitall()` behavior without deadlock

Impact

• Restores behavioral parity with the eventlet backend
• Prevents thread list leaks in long-running services
• Makes thread lifecycle management safer and more predictable