Bugfix: would not always close connection on error

In the case that an onerror handler had not been set, and eventmachine errors were being caught (see EventMachine.error_handler), the WebSocket would not be closed.
For client initiated closure let client close TCP connection
Support sending close codes 1000 & 3000-4999

This is consistent with the behaviour of the major browsers (tested safari, chrome, firefox)
Removed defaulting to close code 1000

The browsers simply send no code if no code is specified, we may as well be consistent.

Browsers (tested safari, firefox, chrome) will report code 1005 to indicate that no code was specified
Added close code reporting to test page
Rename #close_websocket to #close

(to be consistent with the browser API)

Deprecated close_websocket
Send reasons with internally generated close codes

The error messages in WSProtocolError should be safe for external consumption and are useful to debug issues
Make close code checking faster

include? is O(n), and in practice 2 orders of magitude slower than this implementation for high close codes
API to check whether close codes are supported
Refactor out some duplication from tests
Improved fake WebSocket clients

Needed an 05 framing client
Removed duplication
Supported sending frames other than text
More complete specs for drafts 5 & 6
Shared spec was missing the most obvious test
Added event to onclose to expose code & reason

(for drafts 06 and above which support this functionality)

The onclose event will now be triggered as soon as the close handshake has been sent, rather than after the tcp connection has closed.
Simple tests for closing ws with code
Documented ping & pong support in readme
Documented how to close and close code handling
Documented other close codes used internally
Echo close status code in close handshake

Not required by spec, but it says this:

"When sending a Close frame in response, the endpoint typically echos the status code it received"
Return close code 1005 when no code in handshake