Algorithm Execution State Service

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.

See merge request !197