Run x86 guests under TCG on one thread

[tamnd]

A 2x2 run of 7.2.8 X64 on server2 had one rucc kernel panic in three runs: Oops: int3 at sched_clock_cpu+0x8, 11 ms after sched_clock: Marking stable. That message comes before static_branch_enable, which patches that site from a jmp to a 5-byte nop. The patch was done and the INT3 handler had given up, but a CPU still ran the INT3.

This is not the compiler. In 58 boots of each kernel under TCG, the gcc kernel and the rucc kernel each had one such oops, at sched_clock_tick and at set_next_task_fair. QEMU 8.2 runs each vCPU on its own host thread by default, and it can let a vCPU run the INT3 after another vCPU has written the old byte back. x86 patches a static key with an INT3 while the other CPUs run, so x86 is the row that sees it. arm64 patches under stop_machine and keeps the default.

With this change rk passes -accel tcg,thread=single for x86_64 and i386 when there is no KVM. The guest still has two CPUs, but one host thread runs both, so each vCPU sees every write to the text in order. KVM is not changed.

On server2 with this rk, 80 boots (40 of each kernel) had no oops. A boot takes longer: the gcc kernel reached init in 24 s and not 8.5 s. The KUnit timing is below.

[tamnd]

Timing with this change on server2, for one KUnit boot of 7.2.8 X64 defconfig+test under TCG with -smp 2:

kernel	before (MTTCG)	after (thread=single)
gcc	290 s	299 s
rucc 0.30.1	392 s	363 s

KUnit runs one test at a time, so a second host thread gave almost nothing. Both boots stay far below the 1800 s timeout. The boot loop before this change had 1 int3 panic in 29 boots for each compiler, and with it there were 0 in 40 for each.

The same run found one splat only in the rucc kernel log: refcount_t: addition on 0 in kthread_stop from test_ratelimit_stress. That is a race in the test itself, which upstream fixes with kthread_should_stop(). A separate PR handles it.