gdb: call update_thread_list after completing an inferior call

gdb: call update_thread_list after completing an inferior call

I noticed that if GDB is using a remote or extended-remote target,
then, if an inferior call caused a new thread to appear, or for an
existing thread to exit, then these events are not reported to the
user.

The problem is that for these targets GDB relies on a call to
update_thread_list to learn about changes to the inferior's thread
list.

If GDB doesn't pass through the normal stop code then GDB will not
call update_thread_list, and so will not report changes in the thread
list.

This commit adds an additional update_thread_list call, after which
thread events are correctly reported.