[gdb/testsuite] Extend gdb.base/kill-during-detach.exp

[gdb/testsuite] Extend gdb.base/kill-during-detach.exp

I ran into the following FAIL:
...
(gdb) python kill_and_detach()^M
Traceback (most recent call last):^M
  File "<string>", line 1, in <module>^M
  File "<string>", line 7, in kill_and_detach^M
gdb.error: Selected thread is running.^M
Error while executing Python code.^M
(gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: \
  python kill_and_detach()
...

The FAIL happens as follows:
- gdb is debugging a process A
- a checkpoint is created, in other words, fork is called in the inferior,
  after which we have:
  - checkpoint 0 (the fork parent, process A), and
  - checkpoint 1 (the fork child, process B).
- during checkpoint creation, lseek is called in the inferior (process A) for
  all file descriptors, and it returns != -1 for at least one file descriptor.
- the process A continues in the background
- gdb detaches, from process A
- gdb switches to process B, in other words, it restarts checkpoint 1
- while restarting checkpoint 1, gdb tries to call lseek in the inferior
  (process B), but this fails because gdb incorrectly thinks that inferior B
  is running.

This happens because linux_nat_switch_fork patches the pid of process B into
the current inferior and current thread which where originally representing
process A.  So, because process A was running in the background, the
thread_info fields executing and resumed are set accordingly, but they are not
correct for process B.

There's a line in fork_load_infrun_state that fixes up the thread_info field
stop_pc, so fix this by adding similar fixups for the executing and resumed
fields alongside.

The FAIL did not always reproduce, so extend the test-case to reliably
trigger this scenario.

Tested on x86_64-linux.

Approved-By: Kevin Buettner <kevinb@redhat.com>
PR gdb/31203
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203