Log event handling logic split between Logger and LoggerContext (#3)

The logger now creates the LogEvent instance and sends it to the
underlying LoggerContext for processing. In turn, the LoggerContext
will typically just give it back to the Logger, provided that the
context-wide filter does not reject the event and provided that
Woodman is indeed started.

That's a first step towards being able to cache events in memory while
Woodman is being started.
Log events kept in memory while Woodman starts (#3)

The logger context now keeps log events it receives before the context
is up and running in memory. It processes the events as soon as the
context is operational.

To avoid out of memory issues, the context only keeps the last 1000
most recent log events in memory. It logs a warning when messages had
to be discarded.

The maximum number of log events kept in memory may be adjusted
through the "maxPendingEvents" configuration setting. Beware though:
by definition, this setting can only be taken into account when
Woodman is initialized!
A few unit tests added for synchronous load method (#3)

The tests ensure that events are kept in memory while Woodman starts
and processed afterwards.
The end of the format string was lost when substitution was used (#13)

Fixed. Added a regression test to ensure this does not come to bite
us again.