GMR-197: Algorithm Execution State Service

apply Gaudi Merge Request 197: gaudi/Gaudi!197 (merged)

Introduction of AlgExecStateSvc

All event state information removed from Algorithm base class (m_filterPassed, m_isExecuted) as it will cause difficulties with re-entrant Algorithms.

event success/fail flag removed from EventContext

These flags are moved to be under control of a new service, the AlgExecStateSvc, which keeps track of the execution state of all Algorithms, and the Event as a whole.

Algorithm status kept in a new class AlgExecState which has

     bool m_filterPassed  {true};
     bool m_isExecuted    {false};
     StatusCode m_execStatus  {StatusCode::FAILURE};

AlgExecStateSvc holds an AlgExecState for each Algorithm in each Event Slot, as well as an overall EventStatus for each EventSlot, which can be one of

   Invalid = 0,
   Success = 1,
   AlgFail = 2,
   AlgStall = 3,
   Other = 4

Algorithms add themselves to the AlgExecStateSvc upon initialization, but the Service's initialization of the data structures is deferred until the first time AlgExecStateSvc::reset() is called, at which point it's probably safe to figure out if there's a WhiteBoard, and the number of slots to allocate.

The EventLoopMgr should call AlgExecStateSvc::reset() at the start of each event. If it's a concurrent EventLoopMgr, it should be AlgExecStateSvc::reset(EventContext), after the EventContext object has been updated to reflect the new event.

Also added an EventContext object to the MinimalEventLoopMgr, so that serial/concurrent behaviour is similar.

Concurrent queries to the AlgExecStateSvc must contain the EventContext, so the correct EventSlot can be determined. Serial access is via methods that don't have the EventContext as a parameter. For access from Algorithm base class (eg from setFilterPassed, isExecuted, etc), if the EventContext ptr (m_event_context) in the Algorithm is null, we assume we're running serially.