introduce multiple tiers of `Event`s

[michaelsippel]

An Event represents a node of the scheduling-graph. Each task is associated with multiple events, describing execution states before (pre_event) and after (post_event) the task execution, as well as the state of the task-result, being initialized (result_set_event) and retrieved (result_get_event).

The Scheduling-Graph is implemented as Out-List, meaning each vertex stores a list of outgoing-edges , called followers.
However this abstraction has some not insignificant special cases which we ought to optimize.

E.g. for CPU-Tasks we know, that the pre_event will never receive any followers. Thus the whole followers list and all associated follow up- checks in Event::notify() could be omitted for this kind of event.
For other kinds of events , e.g. the result_set_event & result_get_event will not be needed by any task which returns void ( this includes all cuda-tasks ).

Implementation could be done as class-inheritance hierarchy.

// only counts number of in-edges
template < typename incount_t >
struct SinkEvent { atomic< incount_t > state; };

// keeps out-edges
struct SourceEvent : SinkEvent { ChunkedList< EventPtr > followers ; };

// this event can wake up a worker 
struct WakingEvent : SinkEvent {  WakerID waker_id;  };

// signals that the task must live at least until this event is reached
// `notify()` will release the ownership of the task when the event is reached
struct TaskRefOwnEvent;

struct CPUTask {
    // pre event is only used to check if task is ready, therefore only needs to be SinkEvent
    struct PreEvent : virtual SinkEvent {};
    // post event is always source
    struct PostEvent : virtual SourceEvent , TaskRefOwnEvent {};

    struct ResultSetEvent : WakingEvent {};
    struct ResultGetEvent : TaskRefOwnEvent {};
};
struct CudaTask {
    // a cuda task must be able to notify other tasks through the pre-event.
    struct PreEvent : SourceEvent {};
    struct PostEvent : SourceEvent {};
};

evaluation:

• (+) would save us a lot of bytes per task.
• (-) might require v-table for Event
  • (->) maybe solve this by encoding the type into EventPtr with bitmagic
• (?) how can the event types be known statically
  • (->) need to select a specific event-configuration for each task.
  • (->) provide possibility to enable/disable optional Task-Properties via template in emplace_task() ?