Removed 'flushing' from matcher testsuite

Previously we had used a technique called 'flushing' to make assertions
about things events which did not happen inside the matching engine. An
example would be a test which asserted that two orders did no result in
a match. Using flushing we would push a few unrelated messages into the
matching engine and that would ensure that no other messages had come
back from the matching engine in the mean time. This approach relied on
the fact that the underlying tests were checking for ACK messages and so
if we pushed though an unrelated message and could only see its ACK
on the message queue we knew that no other messages had been generated.

This doesn't work anymore. Because we have the message handling system
found in the coordinator/ package the ACKs are invisible to the test
system and 'flushing' no longer works. Existing tests using 'flushing'
have been changed to use some other approach with explicit Expect(...)
function calls.

Minor changes include:

Added svr binary to gitignore
"udp" was "upd" in tutil_test.go
Refactored coordinator to solve deadlock issue

The coordinator now arranges three goroutines like so

<network> -> listener -> app -> responder -> <network>

A clear consequence of this design is that the app now sees all
messages, including 'noise' like ACKs etc. For this reason the
coordinator provides a helper function Process(*msg.Message) which
automatically filters and forwards messages not intended for the
application.

We also added a q/ package to allow us to reuse the in-memory
ReadWriteCloser implementations that were popping up in tests all over
the place. The work of removing all local imlementations of the
ReadWriteClosers is still ongoing.

Extra notes:

Previously we had a central dispatcher through which each of the three
components communicated. Messages would go into the dispatcher and be
routed to their next destination. Because the dispatcher has a bounded
queue (go channel) this design is very prone to deadlocking. The
original design is based on one which uses a memory mapped file to
implement a fast persistent queue. Without an unbounded queue the
dispatcher based design is unworkable. Several attempts were made to
fix these issues but deadlocks would reappear again and again.

A centralised dispatcher had allowed us to conveniently log every
communication made within a server without requiring a mutex to protect
the logger. Although no persistent message logging is implemented here
it seems likely that it will be done at the 'app -> responder'. But this
is simply speculation at this stage.

Applications will want now to make use of the AppMsgHelper struct,
which provides pre-setup channels and also the useful Process(...)
method. Because of this the coordinator cannot depend on any other
packages and so the integration style tests calling into the matcher's
testsuite have now been moved into the matcher/ package. So it is the
matcher which tests that the matcher and coordinator packages integrate
properly.