Reconsider modelling awakeables not as signals in the service protocol

[tillrohrmann]

Currently, awakeables are modelled as signals in the service protocol. Signals denote external events that don't have an origin in the journal. Apart from awakeables, control signals are modelled as signals (e.g. a cancellation). Due to their "external" origin, signals don't have an origin entry in the journal.

In context of reviewing #3186 (issue #2890), it became evident that modelling awakeables as signals has two major shortcomings:

1. Because creating an awakeable does not create an origin journal entry, it is not possible to properly fence off awakeables that originate from before the log was reset to a point before the awakeable was created. This can cause correctness issues because the second time an awakeable is sent (e.g. to an external system), it might be sent with different arguments and will expect a different return value.
2. Because creating an awakeable does not create an origin journal entry, it is not possible to automatically decide whether an awakeable signal/completion should be kept when resetting the log. If there were an origin entry, then one could keep the signal/completion if the origin entry is kept and otherwise one could drop it (similarly to commands and their completions). As a consequence, resetting a journal will now require user input to tell us which awakeables should be kept/removed.

Based on these findings, it seems that modelling awakeables such that creating of an awakeable will result into a journal entry and the signal becoming something similar to a completion might be the better fit.