isl: built-in 104 is request_next -- named from the game's own log string

Followed the writer, not the reader.  [phase+10160]'s only writer in
the image is one site in the mission frame loop sub_821AA1B0: it does
obj->get() on an object fetched from a registry by id 0x20FFFF02,
stores it to the phase, then clears the object -- read, publish, clear,
every frame.

The id namespace has exactly three members (0x20FFFF00/01/02), each
built at exactly 4 sites, and two of those are in sub_821D5178, which
gets 0x20FFFF01 and 0x20FFFF02 and logs both:

  GamePart_ReadyRoom::Impl::OnCommand - Wait() command is requested.
  Check flow control valiables. WAIT_MODE : %d, REQUEST_NEXT : %d

Argument order gives 0x20FFFF01 = WAIT_MODE, 0x20FFFF02 = REQUEST_NEXT.
PrepareScript corroborates: it sets WAIT_MODE=1, REQUEST_NEXT=0 before
an ISL script runs.  So the six tutorial stages' lone dominating
condition request_next() != 1 is the script waiting on the game part's
proceed flag.

6 artefact lines changed, all 6 pair exactly.

tools/re-capture/isl.py

@@ -110,7 +110,7 @@ BUILTIN = {
     81: 'banner_objective_update', 82: 'banner_mission_failed',
     135: 'banner_mission_restart',
     93: 'stopwatch_stop', 94: 'is_engaged', 95: 'unit_hp_pct', 100: 'reset_phase_threads',
-    102: 'prompt_yes_no', 108: 'deploy_squadron_ex',
+    102: 'prompt_yes_no', 104: 'request_next', 108: 'deploy_squadron_ex',
     109: 'set_unit_flags', 115: 'named_event',
     120: 'wait_cmds_drained', 123: 'timer_resume', 124: 'timer_stop',
     125: 'timer_reset', 126: 'timer_elapsed', 127: 'timer_set',