Optimise the Luxi.recvMsg function

Since the current buffer cannot contain (during network reads) an EOM,
we should look for the EOM only in the newly-received string.  While
this shouldn't make much difference, in some tests it cuts the recvMsg
total time by around half.

On entering recvMsg, we have though to search the old buffer for a
message though, since we could have received two Luxi messages on the
last network query; this is however a one-off cost, compared to
continuously looking for the EOM in the old string (at each receive
loop).