[StreamToHandshake] Clearly define the semantics of the init ctrl signal

[Dinistro]

As of now, the init ctrl signal/token is only used in the create operation. To get consistent lowerings we have to decide how this signal is used and in what order the operations receive this signal.
Furthermore, it's not yet clear if the result should be returned or not and what the final return will output.

See the lowering of sink and how it gives a weird handling of the ctrl signal.

[Dinistro]

A potential approach is the following:

Some operators have internal state that has to be initialized. As handshake doesn't give access to the reset signal and some circuits will require occasional re-initialization, we do provide an "init ctrl" that triggers such a reset. It is assumed (or enforced) that all operators can be reset independently and that they emit a "ctrl" signal on completion. Therefore, a handshake function can emit a "ctrl" signal once all it's operators produced such an output. This in turns allows the input to the function to be connected to all operators and the ReturnOp will join all their outputs and thus only emit if all are finished.

Note that the interaction with create must be considered. create should in fact only start to emit stream elements once all other operators are initialized.

[Dinistro]

I'm not sure if we require this any longer. We will only support registers as state, and they can be reset with the according signal.
Reading in external values can also be done with streams + registers.

The start operation could in theory be replaced with inputs provided by the tests, but for now we can keep the ctrl signal there to trigger them.