Make Eio.Condition lock-free

[talex5]

This makes Eio.Condition safe to use from a signal handler (see #374).

It's also faster. Before (using locks):

$ dune exec -- ./bench/bench_condition.exe
use_domains,  ms/iter, promoted/iter
      false,    3.93,        0.0000
       true,    9.62,    25513.410

After:

$ dune exec -- ./bench/bench_condition.exe
use_domains,  ms/iter, promoted/iter
      false,    1.12,        0.0000
       true,    2.71,    13066.2100

This is based on the paper A formally-verified framework for fair synchronization in kotlin coroutines.

The key part is cells.ml (based on Appendix C in the paper), which implements an infinite list of cells as a linked-list of segments, each containing an array of cells. When all cells in a segment are cancelled, the segment is removed from the list.

broadcast.ml then uses this to build a queue of waiters that can all be woken at once. Eio.Condition uses this to suspend and resume fibers. Broadcast isn't described in the paper; I had to add a resume_all operation to allow it. They do have a "Barrier", but that requires a separate counter and seems to have problems with cancellation ("Thus, similarly to the implementation in Java, we do not support cancellation."). I'm not sure why they didn't add a resume_all themselves.

lib_eio/tests/broadcast.md shows an example of how to use it.

lib_eio/tests/dscheck contains some tests that try to explore all possible interleavings of atomic operations. However, the official version runs out of memory and crashes after about 30s, while the optimised version has a known bug that may cause it to miss bugs.

It should be fairly easy to use this code to make the other synchronisation primitives lock-free (#382). The paper suggests creating a single abstraction to handle all cases, but I suspect it would be easier to create several simpler ones.

I want to read over the paper again and check it against my code, but it seems to be working well at the moment.

/cc @kayceesrk @bartoszmodelski @lyrm