"Handle" frames with a data length of zero.

These frames were already not allowed in the binkp/1.0 protocol,
and it is mentioned in the spec (issued in 2005) as "Some old
implementations do send empty frames as the last frame.".

It's certainly not allowed now, and any mailer which does it is
broken.

For zero-length data packets, it will be seen as a frame containing
zero data bytes which will also be logged as being after the file
if it comes after the file has already been completely transferred.

A zero-length command packet will abort with M_ERR, logging an error
regarding command number NaN or something like that.

This may fix #185 since attempting a recv() of zero bytes and
succeeding is the only way I can see for a zero second timeout to
have been logged in receving frame data.  The software assumed that
receiving zero bytes was a timeout, but if that's what you asked for,
it's actually success.