Discussed in #253

The problem: Using the Read method on a file which is filled externally, lets the trice tool trying again and again.
In the FILEBUFFER case, the COBS Read could return internally (0, nil) without reaching the end. As workaround the function decodeAndComposeLoop now contains a timeout of 100ms for the FILEBUFFER case. A better solution would give the newCOBSDecoder function and its relatives an aditional parameter, telling them if the data source is endless (like an UART) or has an end (like the FILEBUFFER). In the FILEBUFFER case there is a 2nd open qustion: Trices are printed out only if a line is complete ("\n"). A line can consist of several Trices. If the FILEBUFFER´s last Trice messages are without "\n", they would not displayed. To avoid that, a newline is added at the end. So the last displayed line of a FILEBUFFER could be incomplete.