This improves cli handling in a wide variety of ways. Let's point one at
a time.

Change how we match sent command to not have issue with line break
caused limited number of columns. Now it simply expects new line and
return characters while it looks for characters from command. This makes
it possible to remove hack to increase number of columns in Shell.

The initial prompts in Shell were sanitized a little bit and commented.
The "weird" prompt it turns out is caused by TERM variable and remote
shell trying to control local terminal. One solution would be to set
different TERM but that complicates mterm usage while debugging. The
alternative and used option is to simply simplify regular expression to
not have problem with it. With exception of Busybox's default prompt
they are specific enough without having to match also new line.

For the same reason as in previous paragraph the nsfarm prompt was also
simplified. It now matches new lines only optionally. The reason is also
that not every program terminates with new line at the end and so it is
completely possible and valid that prompt is displayed at the end of
line not at the beginning. The "nsfprompt" is also specific enough word
that should not be anywhere else that we can rely only on it when we
look for our prompt.

This also fixes txt_write and bin_write as sendeof does work only on
pexpect instance but not on fdexpect. The more correct and used option
here is our own ctrl_d function that only signals EOF without actually
closing stdin.

The txt_read and bin_read methods gets option to not fail if file does
not exist. The txt_write method also got option to append instead of
overwrite.

The logging was improved by implementing our own code that splits lines.
The splitlines method is little bit too aggressive with splitting as it
expects pretty reasonable new lines consistency usage with standards.
The issue here is that for example '\r' that moves cursor to the left
can be spawned multiple times and has no effect and in some cases that
is what happens. The combination '\r\r\n' should be only one line not
two as detected by splitlines. The code we now use detects combination
of any number of '\r' and single '\n' as a one line split. It also
handles only '\r' as that is commonly used to overwrite existing line so
we consider it as new line as well. There is still a room for
improvements such as support for backspace and other control characters.