Greatly reduced the number of INCOMING messages

The way tailing works, it reads files in burts with delays between them. In practice, this results in multiple lines of the file being read at once, and then no lines being read.

Until now, *Splitlog* has processed each line separately and waited for the next line to decide whether the previous line is already a full message. And before that next line arrived, it sent the previous line as ```MessageDeliveryStatus.INCOMING```. This behavior wasn't very easy to explain and it certainly was not expected by users of the tool.

With the recent refactoring of the Tailer, we are now able to tell when the read burst starts and when it ends. Therefore, between these two events, we will not emit ```INCOMING``` messages. Instead, we will buffer the lines for as long as we can. The only time that Splitlog will now emit an ```INCOMING``` message would be at the end of a burst, when the last line being read couldn't be identified as an end of a message. 

Furthermore, the last message before the tailing is terminated will now also be transformed to either ```ACCEPTED``` or ```REJECTED```. Until now, it was only ever ```INCOMING```.

This pull request changes the way that *Splitlog* works in a manner that is backwards compatible. Users will only be affected if they are specifically binding their Expectations and Metrics to the ```INCOMING``` messages. It also deprecates the ```INCOMPLETE``` message delivery status, which is going away without a replacement.