The only difference betwenn the two traits is the additional Send bound. We should unify this again using the trait-level impl trait feature once it's stable.

Add convenience functions for merging external event streams with `EventStream`

Map shared memory region as read-only in receiver

Add convenience function `send_output_bytes`

Our upcoming ros2<->dora bridge will allow nodes to subscribe to ROS2 topics, which results in a second stream of events. By providing a merge function, this ROS2 event stream can be merged together with the dora event stream.

It's common to send a byte array that already exists, so it makes sense to provide a convenience function for this use case.

The maintainer of the `shared_memory` crate did not react to our PR, so I decided to create a (temporary) fork.

This ensures that the data is not modified, even if shared with Python as zero-copy arrow array. Modifying the data could result in undefined behavior since there might be other subscribers that read the data at the same time.

Instead of doing an additional copy to send them from the operator thread to the runtime thread.

This commit uses the new `allocate_data_sample` and `send_output_sample` methods introduced in d7cd370.

This provides an alternative way to send outputs with less lifetime restrictions than the closure-based interface.

Reuse same event type as for Python node API.

We don't want to keep the input open until all drop tokens were released for two reasons:

- It adds an unnecessary delay. It is already clear that the output is finished, so by reporting it directly receivers can react earlier.
- Receivers might be blocked while waiting for new events, which prevents them from sending finished drop tokens. By closing the outputs, they will be unblocked through a new `InputClosed` event, which allows them to send their finished drop tokens. This way, we receive the remaining drop tokens faster in the sender.

The Python garbage collection will drop them non-deterministically in the background. Also, the dropping cannot happen while the GIL is held by our wait code.

There might still be some pending drop tokens after the receiving end of the event stream was closed. So we don't want to break from the receiver thread directly. Instead we keep it running until the control channel signals that it expects no more drop tokens by closing the `finished_drop_tokens` channel. This happens either when all required drop tokens were received, or because of a timeout.