gdb, btrace: switch threads in remote_btrace_maybe_reopen()

In remote_btrace_maybe_reopen() we iterate over threads and use
set_general_thread() to set the thread from which to transfer the btrace
configuration.

This sets the remote general thread but does not affect inferior_ptid.  On
the xfer request later on, remote_target::xfer_partial() again sets the
remote general thread to inferior_ptid, overwriting what
remote_btrace_maybe_reopen() had done.

In one case, this led to inferior_ptid being null_ptid when we tried to
enable tracing on a newly created thread inside a newly created process
during attach.

This, in turn, led to find_inferior_pid() asserting when we iterated over
threads in record_btrace_is_replaying(), which was called from
record_btrace_target::xfer_partial() when reading the btrace configuration
of the new thread to check whether it was already being recorded.

The bug was exposed by

    0618ae4149 gdb: optimize all_matching_threads_iterator

and found by

    FAIL: gdb.btrace/enable-new-thread.exp: ... (GDB internal error)

Use switch_to_thread() in remote_btrace_maybe_reopen().

gdb/remote.c

@@ -14136,7 +14136,7 @@ remote_target::remote_btrace_maybe_reopen ()
 
   for (thread_info *tp : all_non_exited_threads (this))
     {
-      set_general_thread (tp->ptid);
+      switch_to_thread (tp);
 
       memset (&rs->btrace_config, 0x00, sizeof (struct btrace_config));
       btrace_read_config (&rs->btrace_config);