Purge any pending receive data before sending the YMODEM header block.
This helps to insure that the next byte received from the receiver
(ACK, NAK, 'C' or 'G') is an actual response to the header block we sent and
not some other pending receiver start-request.

The problem that was observed was upon YMODEM-G uploads to the BBS/sexyz, the
receiver (sexyz) would send a few 'G's before the sender (e.g. SyncTERM)
would get around to sending the YMODEM header block (while the user selects
the file path/name to upload, takes a few seconds). The sender would see
the first of these buffered 'G's received while selecting a file as an
acknowledgement of the header block and then immediatley start sending file
data. Meanwhile, the receiver sees incoming file data *before* he actually
acknowledges the header block and throws it out as unexpectd data, so we're
out-of-sync and with YMODEM-G there is no recovery/retry scheme.