Reland "Reland "[ios blink] Implement futures using WaitListEvent""

This is a reland of commit a218ceac197ff55273d80942e114eea9d6dcc90c

The only substantive change over the original is that we release the
waiterLock before iterating through the events at the end so that TSAN
doesn't get tripped up by the benign lock order inversion between
SyncWaiter::mutex and WaitListEvent::mMutex.

Original change's description:
> Reland "[ios blink] Implement futures using WaitListEvent"
>
> This is a reland of commit abc42736ef28ed8fcc11e66814907febff6ee930
>
> The only change over the original is the correct initialization of the
> `mSignaled` atomic_bool in WaitListEvent.
>
> Original change's description:
> > [ios blink] Implement futures using WaitListEvent
> >
> > Currently, most futures are implemented using SystemEvent. This includes
> > already completed and non-progressing events. This is problematic on iOS
> > where BrowserEngineKit child processes are not allowed to open fds, mach
> > ports, etc.
> >
> > This CL introduces WaitListEvent which mimics the base::WaitableEvent
> > implementation in Chromium for POSIX platforms. The event internally
> > maintains a list of waiters corresponding to a WaitAny call. In WaitAny,
> > we create a SyncWaiter that's signaled using a condition variable. The
> > waiter is added to each event that the WaitAny is waiting on. The events
> > also have a mutex to allow multiple threads to wait on them. We acquire
> > the event locks in a globally consistent order (sorted by address) to
> > prevent lock order inversion. WaitListEvents can also be waited on
> > asynchronously by returning a SystemEventReceiver which allows mixing
> > waits on SystemEvents and WaitListEvents.
> >
> > In addition, this CL changes how already signaled and non-progressing
> > TrackedEvents are represented. Already signaled events are backed by
> > WaitListEvents and non-progressing events become a flag on TrackedEvent.
> >
> > The code in EventManager is also cleaned up to aid readability and fix
> > an edge case of waiting on multiple queues with zero timeout - we could
> > end up ticking the same queue multiple times causing a subtle race
> > between MapAsync and OnSubmittedWorkDone futures completion.
> >
> > Bug: 407801085
> > Change-Id: I1c5deb8097339be5beb5e9021d753998a074bea3
> > Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/234277
> > Reviewed-by: Loko Kung <lokokung@google.com>
> > Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
> > Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
> > Reviewed-by: Kai Ninomiya <kainino@chromium.org>
> > Commit-Queue: Kai Ninomiya <kainino@chromium.org>
>
> Bug: 407801085
> Change-Id: I254398256851f2310ddfe906c79d389dae1d3d77
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/237719
> Commit-Queue: Corentin Wallez <cwallez@chromium.org>
> Reviewed-by: Kai Ninomiya <kainino@chromium.org>
> Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
> Reviewed-by: Corentin Wallez <cwallez@chromium.org>
> Commit-Queue: Kai Ninomiya <kainino@chromium.org>
> Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>

Bug: 407801085
Change-Id: I31561d82321658370defab8cec37591e35d4c932
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/237723
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>