The previous fix did not take into account the logic in have_line
function, which takes care of certain modems that do not prefix
their responses by <cr><lf> at all. This fix should take both
into consideration
The standard is a bit fuzzy on how multiline responses are returned
GAtChat assumed that they will always start with <cr><lf>, however
this doesn't seem to be correct. Add a new state which is entered
when a response is obtained. If <cr> is encountered, then it
is processed regularly, otherwise the parser assumes that the
next line is part of the multiline response