Let a thread resume at the instruction after a syscall

[Sinan-Karakaya]

A syscall can hand control back to the scheduler before the instruction after it runs. SetSyscall lets the guest install its own handler for a syscall number; dispatchSyscallOverride then suspends the calling thread and queues that handler as a GuestInvocation. When the invocation finishes, EeScheduler resumes the parent thread at the address the generated code stored just before calling handleSyscall — the instruction right after the syscall.

The analyzer never marked that address as an entry point. queueResumeEntryTarget() is reached for OPCODE_JAL and SPECIAL_JALR only, so no generated function could be re-entered there, EeSchedulers hasFunction() check failed, and the thread was made dormant instead of resumed.

The failure is quiet, which is the annoying part: the thread just stops, the scheduler drains normally, and run() returns 0. It looks like a clean shutdown rather than a fault.

This is reachable during early boot on a real title. Dragon Quest VIII (SLUS-21207) hits it in crt0 — the Metrowerks startup code installs a handler for syscall 0x83 and immediately issues it, so execution ends about ten functions into the binary:

[guest-branch:missing-target] kind=DirectJump op=EE scheduler
  source=0x120a48 target=0x120a48 pc=0x120a48 ra=0x120ae4 ...
  trace=0x10008c -> 0x120b98 -> 0x120948 -> 0x116820 -> 0x116820
        -> 0x120a88 -> 0x120b88 -> 0x120b88 -> 0x120a40 -> 0x120a00

0x120a40 is the four-instruction syscall wrapper (addiu $v1, $zero, 0x83 / syscall / jr $ra / delay slot) and 0x120a48 is its jr $ra. That binary has 175 syscall sites, none of which had a resume entry.

Note the offset is +4, not +8: syscall has no delay slot.

Adds a test covering both the resume entry and the offset.