Add add_nonblocking, capacity and is_full for streams

[xavierm02]

Having a non-blocking add is useful when adding from an asynchronous callback from C code (e.g. an event handler or timeout in Lablgtk) because having the fiber yield would result in an Effect.Unhandled exception.

The simplest solution is to make the stream unbounded by creating it with the max int as capacity, but that has the disadvantage of letting the stream take up a potentially unbounded amount of memory.

Another solution, when using a single domain, is to use the is_full (or capacity) added by this commit, as one can do e.g. (if Stream.is_full stream then ignore (Stream.take stream)); Stream.add stream item.

In a context with multiple domain, this may not work as the lock is released between the take and the add, and another domain might add an element between these two operations. This is why add_nonblocking was also added: defining it from within the module allows to do both operations without releasing the lock in between.

I'm not too sure about Sync.put_nonblocking, and it might be reasonable to just raise an Invalid_argument exception when add_nonblocking is called on a stream of capacity 0.

[xavierm02]

Hm. The Sync.put_nonblocking is probably wrong since it sets the cell value to Slot while it's a producer so it should set it to Item...

[xavierm02]

I removed Sync.put_nonblocking. I'm not sure how to handle the In_transition case.
(take_nonblocking sets the cell's value to a Slot that rejects any value to force the producer to retry sending its value in another cell, but in put_nonblocking, we're supposed to set it to an Item so we can't do that)

[talex5]

capacity and is_full look useful to me.

add_nonblocking seems a bit complicated, and I'm not sure it's that useful:

• With lablgtk the consumer will typically be in the same domain as the callback, so the race there isn't a problem.
• Even with multiple domains, if length < 100 then add t x is good enough to prevent it growing without bound. In fact, since lablgtk is the only producer it will always work perfectly. If there were multiple producers, it could go slightly over, but not by more than the number of producer domains.
• I'm also not sure what kind of events could be dropped. For e.g. keypresses, I think you'd want to keep everything the user enters. For events where you just need to know you need to update (e.g. pointer motion events), you can use Eio.Condition instead.