Do not require storage of deliveryId in application-specific events

[krasserm]

Application-specific events used as confirmation events in context of ConfirmedDelivery shouldn't care about deliveryId storage (as extra field, for example). Instead, the following re-design of ConfirmedDelivery is proposed:

• optional deliveryId field in DurableEvent
• storage of confirmation events is done with persistConfirmation, a specialization of persist that has an extra deliveryId parameter. The persistConfirmation method is defined on ConfirmedDelivery.
• event handlers don't have to call confirm any more. If a DurableEvent with a defined deliveryId is received, the corresponding reliable message is automatically removed from the internal delivery queue (if the event's emitterId equals the actor's id).