Espruino Wifi Socket recovery

@Gordon, same fix as me, thanks for the continued support. This has been a massive step forward and the board has been running all night with one socket broadcasting UDP data from the serial port and another one receiving an incoming TCP stream. I think this will help a number of other libraries (MQTT etc) to appear way more stable. Nice work !

The only other small one I had to catch was quite subtle so I will report it. Occasionally the AT module only receives single bytes at a time and at the end of one of these periods there is sometimes a character missing. A typical sequence looks like this

"\r\nRecv 31 bytes\r\n\r\nSEND OK\r\n"
"\r"
"\n"
"O"
"K"
"\r"
"\n"
">"
" "
"\r\nRecv 52 bytes\r\n\r\nSEND OK\r\n"

and everything is fine but sometimes the last \n is missing and the sequence looks like

"\r\nRecv 31 bytes\r\n\r\nSEND OK\r\n"
"\r"
"\n"
"O"
"K"
"\r" <-- missing \n
"OK\r\n> "

The logic of the parser then breaks as everything is split on \r\n. My (hacky) solution was to check for the situation within the AT module as follows, but it seems to be hiding an underlying issue.

ser.on("data", function cb(d) {
    //console.log(JSON.stringify(d));
    if (line=='\r' && d.charAt(0) != '\n') line = "\r\n";

I have seen other situations with a UART that will miss just the last character when receiving data. I have tried running the Wifi serial at everything from 115200 all the way through to 921600 with a similar result.

Posting more for your information than anything else as I can fix it in my implementation.

Regards,

Steve