Threads: Context switches cost what they do on hardware

Timed on a PSP, each way of handing the CPU to another thread (the call
and the switch together):

                                     hardware   before   now
  rotate to an equal thread              7        14       7
  signal, better thread runs            10        17      10
  it waits again, back to caller        10        19      12
  wakeup, better thread runs             8        13       6
  it sleeps again, back to caller        7        12       6
  start a better thread, entry          30        28      30
  thread ends, back to its waiter       21        13      20
  notify, better thread's callback      14        13      14

A switch between two threads now costs 1150 cycles instead of 2700.
Starting a better thread costs 2000 cycles more, ending a thread 3300,
and setting up a callback 1800.

Also splits a wait timeout's ~30us into the deadline being taken 12us
into the call and the timeout going off 18us after it. That only changes
the time left written back, which threads/semaphores/wait and
threads/fpl/cancel pin between them. intr/vblank is re-recorded so it
no longer depends on the phase of the frame.

threads/callbacks/combos now passes.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

test.py

@@ -392,6 +392,7 @@ tests_good = [
   "threads/mutex/unlock",
   "threads/mutex/unlock2",
   "threads/scheduling/dispatch",
+  "threads/callbacks/combos",
   "threads/scheduling/delayzero",
   "threads/scheduling/dispatchwake",
   "threads/scheduling/mutexhandoff",
@@ -608,7 +609,6 @@ tests_next = [
   # These two mbx tests only appeared to work because they papered over bugs 
 
 
-  "threads/callbacks/combos",
   "threads/scheduling/scheduling",
   "threads/threads/create",
   "threads/tls/memory",