fork noVNC, rename to websockify, cleanup.

Split of wsproxy from noVNC and rename it websockify.
include/websock.js: client library for websockify.

The Websock object from websock.js is similar to the standard
WebSocket object but Websock enables communication with raw TCP
sockets (i.e. the binary stream) via websockify. This is accomplished
by base64 encoding the data stream between Websock and websockify.

Websock has built-in receive queue buffering; the message event
does not contain actual data but is simply a notification that
there is new data available. Several rQ* methods are available to
read binary data off of the receive queue.
Convert wstelnet to use Websock.
Make wstelnet.html more prominent earlier.
Only disable local echo if server is doing echo.

This makes the client usable for other plain text services that telnet
clients can normally communicate with (IRC, SMTP, etc).
Do not hang on non-ready client connection.

Wait 3 seconds for the client to send something. If no data is
available within 3 seconds then close the connection. It's probably
a non-WebSockets client that is waiting for the server to say
something first.
Strip "ws" from test names. Update TODO.

Also, rename wstest to load.
Update to gimite/web-socket-js 20f837425d4.

20f837425d4 changes to a single event stream handler fixing the
recursive call errors in firefox and Opera.

Also, pull web-socket-js fix from noVNC

    Related to this issue:
    https://github.com/gimite/web-socket-js/issues/#issue/50

    This prevents the "Uncaught exception: TypeError:
    'this.__handleEvents' is not a function" everytime the timer fires.
Fix firefox 4 strict complaint.
Add latency test and browser latency test results.
Fix web-socket-js commit hash.
Tolerate some bufferedAmount and send() return value.

- Only delay sending data if bufferedAmount is greater than 1000.

This seems to match the intention of the spec better. bufferedAmount
does not mean that we can't send, it's just an indication that the
network is becoming saturated. But Opera 11 native WebSockets seems to
have a bug that bufferedAmount isn't set back to zero correctly so

- websock.send returns true/false.

If all send data was flushed from the send queue then return true,
otherwise false. This doesn't mean the data won't be sent, just that
it wasn't sent this time and is queued.
Use websock.js in latency test. Fixes for Opera.

Convert latency test to use include/websock.js instead of direct
WebSockets handling.

Add support for configuring the maximum bufferedAmount. This allows us
to configure it high enough to get around a bug in bufferedAmount
reporting in Opera.

Add some latency test results for Opera 11 with WebSockets turned on.
Re-order and fix sections.
Add some notes about the methodology of the test data.
Typo.
Reap websockify zombies. Add IE9 fix for websock.js.

Reap websockify zombies. Fixes:
https://github.com/kanaka/noVNC/issues#issue/47. Thanks NeilW.

Changes to get web-socket-js to work with IE9. Right now it's a hack to get
around: https://github.com/gimite/web-socket-js/issues#issue/41. The hack is to
disable caching of the flash objects by appending "?" + Math.random() to the
end of the flash object path (but only when using IE).
Better reaper, catch occasional bad WS header line.

Call waitpid in loop to catch SIGCHLD signals that happen while
handling the original SIGCHLD signal.
Pull JSLint'ing from noVNC.
Update web-socket-js to bb5797cad.

Primary change is removal of FABridge interface.

Seems to improve overall latency by perhaps 10%. Also, the slowdown
over time in Opera is about half as bad (but still there).