"Test suite didn't report a result" on macOS-arm64

[mhsmith]

This has now happened in 2 out of the last 3 merges to main:

• https://github.com/beeware/toga/actions/runs/9758697720/job/26933930733
• https://github.com/beeware/toga/actions/runs/9688032611/job/26733879177

[freakboy3742]

This is proving very difficult to narrow down, because it's essentially not reproducible; re-running the same task almost always results in a successful test pass.

Looking at the failure mode: the error being reported is that the test suite didn't report a result - which means that Briefcase isn't seeing the >>>> EXIT ... test sentinel.

One observation is that the problem appears to coincide with log messages that read:

=== Messages dropped during live streaming (use `log show` to see what they were)

This run is a recent run that demonstrates this well. This suggests the issue might be that issue is that Briefcase is losing the log tail, and as a result, isn't seeing the sentinel value; but the process is exiting, so Briefcase is able to detect that the app has completed.

If this hypothesis is correct, there are three possible fixes:

1. Use a mechanism other than the system log for tailing results. I'm not sure what that mechanism would be, though.
2. Modify Briefcase so that, in the case where no sentinel is seen, an additional call to log show is made to get the last N lines of the system log. From what I'm reading, log show is guaranteed to return all log output, so
3. Modify the test execution so that log streaming isn't needed. Log streaming is currently needed because the test suite is executed inside the app, so we are reliant on the app's output to evaluate test success. One of the approaches to Add testbed support for web backend #2662 is to modify the testbed so that the test suite runs locally, and communicates with the app via a remote control mechanism. This would mean we don't need to use the system log - we could use vanilla stdout handling for test reports.

[freakboy3742]

[Moved to #2732]

[freakboy3742]

I've added a speculative workaround as part of #2666; it's difficult to tell if this will always work, but it at least passed its first CI run.