To provide more info when analyzing failed test cases
an "event" queue (of max size 10) is added to both the
test MG and MGC. This event queue is printed when the
process exist.
Also, the multi_ack_timeout is wonky, so add anther
platform (sunos) to the skip list...

Adjusted some timeouts...
Also, add time stamp to the 'delivery' printouts.

When cancel'ing a timer, the ok return is either:

     ok

or

	{ok, Remaining}

The test case did not handle this (expected 'ok').

When waiting for the server command handler to start
listening, wait only for so long (5 seconds) and if
it has not managed to start listening before then,
we *skip* (because something is wrong with the *system*).

It looked like two messages was received in the "wrong" order,
cuasing the request_and_reply_plain test case tro fail (on
a windows machine).
On closer inspection, the reason was that an "unconditional"
receive was made when waiting for a (disconnect) callback.
But instead we received a secondary message. So, remove
the unconditional receive and instead introduce a timeout
(10 seconds).

It seems that the megaco_config process did not start (for
an unknown reason) and that resulted in a failed test case.
But starting the config process was not what the test case
was for, so it should have resulted in a skip.
Also, since we did not check the result of the config start,
we don't know why it failed.
So, move the start and stop of the megaco_config process
to the [init|end]_per_testcase function(s). If we fail to
start, then we skip (with a useful reason).

The load test suite did not properly handle attempts to
skip test cases. If we failed to start one of the slave
nodes for whatever reason (in this case we got a timeout),
this should not result in a failed test case as this is
out of the control of the test case. As it was, we *did*
try to issue a skip, but the "load controller" did not
detect it. It instead transformed it into a regular error.