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.
That's a fair enough comment. It's not quite true to say the user won't need to worry about it as it affects the signature of the on error callback function (if the user happens to be using the native JavaScript callback option - the C one is fine).

If I'm *really* honest the simple case of passing the file descriptor came about first and I added the message and error code to the on error case as a convenience, because the information was handily available :-) If I'm really really honest ;-D I used the "passing the array" cheat because it kept the "emit" code simple and unchanged when I came to be  passing more stuff.

I guess that there's a couple of options:
If it really bugs I could change the emit code to be a bit more "vararg" friendly and use the arguments pseudo array instead of parameters and use apply instead of call in the body of emit (if you see what I mean?) That would allow me to pass a variable number of arguments to the actual (JavaScript) callback functions.
The other option is to simply update the docs in emscripten.h to mention that the error parameter in the on error callback is actually an array.

I'm veering towards the former approach the more I think about it. It has the downside of making the emit code a bit messier and marginally more expensive - I think that the way to do it would be something like (I think!!):
````
Module['websocket'].emit = function(event) {
	    if ('function' === typeof this._callbacks[event]) {
                  var params = Array.prototype.slice.apply(arguments, [1]);
		  this._callbacks[event].apply(this, params);
        }
      };
````
In other words use the slice/apply idiom to extract the variable number of arguments after the event name into an array and pass that array as the apply parameter.

What do you reckon? the plus side is it will make the on error callback more "obvious" and consistent, the down side is that emit becomes a bit messier and (marginally) more expensive with all the slice/apply shenanigans.