SF: Fix for rare flakes in Event{Control}ThreadTests

This has been a minor issue for a while, and was causing a few failures
a week in the continuous testing infrastructure.

I managed to reproduce it locally with 10k iterations of one test (to
even have a good chance of catching one failure!) -- on a phone that was
stuck in a startup boot crash loop! (Other significant activity), and
from there diagnose it to an extremely rare chance that threads would
take 20-30ms to resume execution after being unblocked, significantly
more than the 10ms maximum time allowed.

This patch increases the maximum wait time to 100ms which should
eliminate the flakes (or at least reduce them to an substantially
smaller percentage of the time).

This led to the discovery that the EventThreadTest destructor was using
the call for expecting an event when actually it should have been making
a call using a lower default threshhold to detect unexpected calls,
which I fixed.

With the tests otherwise using the calls as intended, I verified that
the typical test time was not substantially slower than it was before (in
fact it was faster after the EventThreadTest fix!)

Bug: 112104412
Test: atest libsurfaceflinger_unittest # Not slower for a typical run
Test: EventControlThreadTest.signalsVSyncEnabledThenDisabled * 100k
Change-Id: Ie778567955d746922ef514baff1a552c34794b8d