Feature to enable asynchronous event driven network event handling

Implemented asynchronous event driven network handling.

The current network code works well, but relies on what amounts to polling behaviour where one sets up non-blocking sockets, but then have to rely on periodically calling from a timed loop such as emscripten_set_main_loop because select/poll can't have blocking behaviour in an asynchronous environment like JavaScript.

This pull request provides a mechanism to register callbacks for the key network events from both C code and native JavaScript code. The callbacks are linked to the underlying WebSocket callbacks, but they trigger after the emscripten library calls have done their magic. This means that when the message callback triggers for example there will be data in the socket buffer ready to be read.

The various callbacks are passed the file descriptor of the triggering socket, so it is possible to avoid the use of select/poll as the fd is already known, but equally it's possible to use largely unmodified select/poll based code and just use the async callbacks in place of emscripten_set_main_loop. The test case submitted with this pull request uses that approach.

I've also implemented getsockopt with support for SOL_SOCKET/SO_ERROR, which should hopefully resolve https://github.com/kripken/emscripten/issues/2211

The primary use case for this work is to avoid the need for polling network activity, which will improve efficiency and latency for applications that make use of it. It should also make it easier to incorporate emscripten compiled code in other event loops.
I'll give this a bit of thought. TBH the getsockopt was something of a "bonus feature" :-) as I was doing this I remembered that there was an issue raised around SOL_SOCKET/SO_ERROR and figured I could add something for that as it's somewhat related to what I was working on.

A warning about unimplemented stuff is probably a good idea, I'll check other places where this has been done and follow a consistent pattern.

Why do you suggest returning zero for options we expect to support but currently don't? I guess that the plus side of doing that is that it will allow code that wants the option but doesn't *really* care to potentially carry on, the down side is that it might cause odd results that are a pain to debug (funnily enough if you saw my previous post about pipe I had exactly that scenario where my application didn't treat pipe failing as a fatal error, which was mostly good from my perspective, but OTOH because the implementation was null the pipe file descriptors ended up being zero and one so my app was using stdin when it thought it was the pipe!! I was tearing my hair out for ages trying to figure out what was going on :-)).

I'll ponder this one.....