test(zero-swift): count the busy main actor's time in slices when sending (#131)

URLSessionTransportTests.sendsWhileTheMainActorIsBusy failed on main's iOS
Simulator job at a6e11db with 2 of 200 frames. The whole test process
stalled for about 20 s then: consecutive Network.framework steps of one
connection logged 8 s and 10 s apart, and virtual list tests that don't
touch the network took 14 to 26 s. The main actor's usleep(1 s) ran out
during the stall, and the check ran before the frames' writer, stalled with
it, could catch up.

The main actor now stays busy for 100 slices of 10 ms, the same second,
or until the frames are out, so a stall stretches one slice. Stopping the
test process for 3 s during the wait failed the test 3 of 3 times before
(85, 114 and 110 frames) and passes it 3 of 3 times now. With the writer
back on the main actor, as before #107, it still fails with no frames.

Amp-Thread-ID: https://ampcode.com/threads/T-0d2ed206-a5dd-4f42-9b68-c56e6b23e8f6

Co-authored-by: Amp <amp@ampcode.com>

Author: tmm

swift/Tests/AppleTests/URLSessionTransportTests.swift

@@ -216,8 +216,8 @@
       while !recorder.opened { try await Task.sleep(for: .milliseconds(10)) }
 
       for i in 0..<200 { connection.send("\(i)") }
-      // The main actor stays busy; the frames still go out.
-      usleep(1_000_000)
+      // The main actor stays busy, without suspending, for 100 slices of 10 ms or until the frames are out. Counting slices rather than time means that a stall of the whole process, which CI's iOS Simulator has had for 20 s, stretches one slice instead of using up the second: the frames' writer stalls with it and gets the frames out after. A writer on the main actor gets none out.
+      for _ in 0..<100 where received.withLock({ $0 }) < 200 { usleep(10_000) }
       #expect(received.withLock { $0 } == 200)
     }