Bounded queue

[lyrm]

Following PR #83, this PR adds a bounded queue but non-blocking (like in PR #83) to avoid adding Picos as a dependency to Saturn.

To do

• Add examples in documentation and check with mdx
• Debug the dscheck tests for unsafe version
• Factorize code between unsafe/safe version
• Add benchmarks
• Qcheck tests : use the michael scott ones, and add some with capacity and for of_list
• Add following functions (following Bounded stack #156 API):
  • is_full

Functions not added

• pop_all is not an option as it is very likely to be too much work.
• push_all : would create a lot of starvation and overhead if another thread move the tail before this operation is finished.
• try_compare_and_pop, try_compare_and_push, set_exn etc.. : for a future PR is a good use of these functions is found.

[lyrm]

This PR is nearly complete, but there are a few points to address:

1. Should we keep the current name, Cue?

   • Pros: It’s short and easy to remember.
   • Cons: It may not be very descriptive or expressive.

2. The performance of the safe version is bad. Should I add a note about this in the documentation?

   • I plan to open an issue discussing this, suggesting that we consider using the two-stack queue from Picos as the base for the bounded queue, instead of the Michael-Scott queue (as proposed by @polytypic).

[art-w]

This looks very good! I'm curious if the memory cost of the counter/capacity fields is worth the reduced contention on a shared Atomic? But at the same time, I'm in awe with how smart that technique is :) ... Perhaps one thing to consider (document?) is that TSan users will get "false" data-race reports that they will need to silence ( https://ocaml.org/manual/5.2/tsan.html#s:tsan-runtime-flags )

1. I agree that Cue is a cute name, but that Bounded_queue or Queue_bounded would be more appropriate
2. I think it's expected that the _unsafe variant will be faster with no special need to document it