Error handling B2F message with leading CRLFs

[martinhpedersen]

While testing an unrelated PR I encountered a bug that caused a received message to get lost "in transit" to disk without reporting the failure as an error to the remote station. This resulted in message loss.

So I did some more digging, and found a case where we would end up writing an empty .b2f file that could explain the bug I observed.

If the B2F message we receive is a headerless message (or a message starting with the header delimiter CRLFx2), we end up not reporting any error and just writing an empty message to disk. The empty file written to disk as a result will produce the error I observed when testing this PR. Unfortunately, since the buggy message was lost I can't confirm my theory.

Originally posted by @martinhpedersen in la5nta/pat#426 (comment)