Merge pull request #49 from libricoleur/master

Better support of IPv6
Enable multiple targets in websockify by passing a target-list configuration file.

The --target-list option is used to pass a configuration file on websockify start.

This file contains entries in the form host:port:token, one per line.

When a new connection is open (from noVNC for example), the url should look like:

ws://websockify_host:websockify_port/?token=ABCD

The token is then extracted and checked against the entries in the configuration file.

When the token matches, the connection is proxied to the host:port indicated in the file.

If the configuration file is a folder, then all the entries from files in it are read.
Move target-list processing to websockify.

websocket.py has no concept of target/proxy so any target processing
should happen in websockify itself.

Also:

- remove URL parsing imports from websocket.py since they are not
  needed with SimpleHTTPRequestHandler doing the parsing.

- read the absolute path of the target_list file on startup since the
  --web option will change directories if set.
websockify: change cfg file syntax and clean up parsing.

Config file syntax is now like this:

----------------------
    # Comments and blank lines are allow
    token1: host1:port1

    token2: host2:port2
----------------------
websocket.py: split out handshake parsing.

This makes it easier to use the websocket code in a WSGI script in the
future.
websockify: rename config opt, fix config dir reading
websockify.rb: correct comment, no SSL support yet.
Fix split out handshake parsing for Hixie.

Need the scheme to be accessible when constructing the response for
Hixie clients.
More verbosity about who closed the connection.
websock.js: jslint comments, debug comments, copyright date
Use WebSocket binary data (no base64 enc/dec) if available.

If typed arrays (arraybuffers) are available and the WebSocket
implementation supports them, then send and receive direct binary
frames and skip base64 encode/decode. Otherwise we just fallback to
the current method of sending base64 encoded strings (with a couple of
extra checks for mode in the send/receive path).

The check for binaryType support in WebSocket is a collosal hack right
now due to the fact that the 'binaryType' property doesn't exist on
the WebSocket prototype. So we have to create a connection to
a localhost port in order to test.

A potentionally big performance boost could probably be achieved by
re-using a larger typed array for storing the data instead of creating
a typed array every time we receive a message.
Simpler (but working) binary support.

Instead of trying to handle the receive queue as a typed array, just
replace the base64 encode/decode with conversion from/to typed arrays
and handle the receive and send queue as before (plain Javascript
arrays).

There is a lot of opportunity here for optimization of course, but for
now it's more important that it work properly.
websock.js: simplify rQshiftStr with apply().
websock.js: make protocols parameter of open().

If no protocols are selected then defaults to ['binary', 'base64'] (or
just 'base64' if there is not full binary type support.

Checks to make sure binary types are fully supported and throws an
exception if they are requested but not supported.
Implement option --idle-timeout

server exits after TIMEOUT seconds if there are no active connections
change --idle-timeout to reset the idle timeout when active
Merge pull request #56 from AricStewart/master

Implement --idle-timeout for issue #55