Given concerns about how this change affects timing, I intend to merge this PR after the other system test PRs

Some questions on this PR:

1. Why do you have concerns about test timings with this feature?
2. Why don't you enable visual highlighters in the two other configs? Useful in case the tests using them fail.

2. Why don't you enable visual highlighters in the two other configs? Useful in case the tests using them fail.

Happy for this to happen. I just started with the most commonly used config.

1. Why do you have concerns about test timings with this feature?

• From casual observation, NVDA is less responsive when using NVDA highlighter.
• I have a theory that contention for execution context on the main thread causes extra overhead for the checking conditions. I found that a low interval value for _blockUntilConditionMet starved the core queue processing. The outcome of this is that the conditions take longer to be met, perhaps not being met before the time limit. This can add seconds onto every condition test, the impact of many condition checks per test, over many tests should add up to a statistically significant change in total test execution time. Merging this change last (and after a number of builds of the other changes have already occurred), allows first establishing a baseline for the execution time. The initial investigation/prototype PR shows some changes to _blockUntilConditionMet to improve this, additionally the strategy for collecting speech has changed. Those changes will be explained further in another PR.