Reintroduce the EventContext class

Another substantial refactoring. Work on the event handler instrumentation
revealed the limitation of the current approach - a single thread-specific
EventRacer log simply does not cut it, because we need multiple active logs at
the same time. For example, cancellation of requests or unload events, occurring
during committing a provisional load go in a different log than the one of the
said provisional load. This changeset does not yet solve the issue, but should
provide mechanisms for solving it.
Delay creation of the EventRacer host part until URL load is comitted

When we create an EventRacer log at the host, the previous log, beloging to
the same site instance, is written to disk and stops receiving messages. When
we create the host log too early (as we did), but don't commit to the
navigation we miss the rest of the action.
Ensure there is no active event-action when sending data to the host
Instrument the NavigationScheduler timer
Instrument ImageLoader
Instrument event handling

For now, create happens-before edges between:
 - creation of an event target and first listener invocation
 - installation of an event listener and first invocation
 - between successive event listener invocations

The handling of a single event is enclosed in a single event-action, no matter
if there are multiple handlers. This will, perhaps, need to be revised in the
future, as it may miss some races this way. Good enough(tm) for now, though.