web-socket-js now has all the functionality and fixes needed for noVNC
so remove the include/as3crypto_patched directory and the
include/web-socket-js/flash-src directory (i.e. the sources for
web-socket-js). This cleans up almost 3K from the include/ directory.

Update to web-socket-js build based on upstream (gimite/web-socket-js)
9e766377188.

Move the whole RFB object to rfb.js. vnc.js is now just the loader
file. This allows an integrating project to easily replace vnc.js with
an alternate loader mechanism (or just do it directly in the html
file). Thanks for the idea primalmotion (http://github.com/primalmotion).

Also, JSLint the various files.

The following API changes may affect integrators:

    - Settings have been moved out of the RFB.connect() call. Each
      setting now has it's own setter function: setEncrypt, setBase64,
      setTrueColor, setCursor.

    - Encrypt and cursor settings now default to on.

    - CSS changes:
        - VNC_status_bar for input buttons switched to a element class.

        - VNC_buttons split into VNC_buttons_right and
          VNC_buttons_left

        - New id styles for VNC_settings_menu and VNC_setting

Note: the encrypt, true_color and cursor, logging setting can all be
  set on load using query string variables (in addition to host, port
  and password).

Client cursor (cursor pseudo-encoding) support has been polished and
activated.

The RFB settings are now presented as radio button list items in
a drop-down "Settings" menu when using the default controls.

Also, in the settings menu is the ability to select between alternate
style-sheets.

Cookie and stylesheet selection support added to util.js.

To change the appearance of the cursor, we use the CSS cursor style
and set the url to a data URI scheme. The image data sent via the
cursor pseudo-encoding has to be encoded to a CUR format file before
being used in the data URI.

During Canvas initialization we try and set a simple cursor to see if
the browser has support. Opera is missing support for data URI scheme
in cursor URLs.

Disabled for now until we have a better way of specifying settings
overall (too many settings for control bar now).

Add new states 'loaded', 'connect' and 'fatal':
- Loaded state is first page state. Pass WebSockets mode message using
  this state.
- Connect indicates that the user has issued a "connect" but we
  haven't gotten an WebSockets onopen yet.
- Fatal is a condition that indicates inability to continue on: right
  now, lack of WebSockets/Flash or non-working canvas.

Move much of the actual state transition code into updateState.

Handle 'password' state better in default_controls.js; instead of
disconnecting, prompt for password to send.

Add comments to updateState indicating possible states.

0 is valid UTF-8, but in order to avoid WebSockets framing, we
encode/decode it as 256.

Also, be tolerant of 0 length messages.

- Change tightpng encoding number to -260 (aliguori provided it until
  an official number can be allocated).

Util.Debug, Util.Info, Util.Warn, Util.Error routines instead of
direct calls to console.*. Add "logging=XXX" query variable that sets
the logging level (default is "warn").

Logging values:
    debug: code debug logging (many calls in performance path are also
           commented for performance reasons).
    info: informative messages including timing information.
    warn: significant events
    error: something has gone wrong

Add message/state pollling in web-socket-js. Since Opera tends to drop
message events, we can dramatically increase performance by polling
every now for message event data.

Also, add more direct calls to update readyState so that it's not
missed when Opera drops events.

Also, lower connect timeout to 2 seconds.

Now working under Arora 0.5.

But not Konqueror 4.2.2 (WebSockets never connects).

IE support with excanvas still pending.

Some default_controls.js jslinting.

Needs to be some modularity between controls you probably always want
(like sending CtrlAltDel) and how the interface is presented and
controlled.

Some basic functions from mootools implemented in util.js.

Also, some more DOM separation. Move clipboard focus logic into
default_controls and canvas and out of vnc.js.

JSLint cleanup.

Also, allow 'include/' to be overridden in VNC_uri_prefix.

Also, move Frame Buffer Update code out of normal_msg into separate
function.

- Implement resizing of desktop pseudo-encoding.

- Also send lowest (fastest) compression level pseudo-encoding.
  Ought be user tweakable.

When extracting the data URI info, much more efficient in firefox to
iterate and push onto an array, then to generate the whole array at
once using the map function.

Chrome is mostly unaffected by this change (might be slightly better).

Also, generate encodings array to send from a list of encodings
instead of being hardcoded generator function.

Also, slightly faster non-base64 (UTF-8) decode.

Move DOM manipulation into include/default_controls.js and update
vnc.html to use it.

Add an example vnc_auto.html which automatically connects using
parameters from the query string and doesn't use default_controls.js.

Reorder functions in vnc.js to put external interface functions at the
top of the RFB namespace.

In colourMap mode there are 256 colours in a colour palette sent from
the server via the SetColourMapEntries message. This reduces the
bandwidth by about 1/4. However, appearance can be somewhat less than
ideal (pinks instead of gray, etc).

It also increases client side rendering performance especially on
firefox. Rendering a full 800x600 update takes about 950ms in
firefox on my system compared to about 1400ms. Round-trip time for
a full frame buffer update is even better on firefox (due to
performance of the flash WebSocket emulator). Reduced from about
1800ms to 1100ms on firefox (for 800x600 full update).

Also add a wsencoding test client/server program to test send a set of
values between client and server and vice-versa to test encodings.

Not turned on by default.

Add support for encode/decode of UTF-8 in the proxy. This leverages
the browser for decoding the WebSocket stream directly instead of
doing base64 decode in the browser itself.

Unfortunately, in Chrome this has negligible impact (round-trip time
is increased slightly likely due to extra python processing).

In firefox, due to the use of the flash WebSocket emulator the
performance is even worse. This is because it's really annoying to get
the flash WebSocket emulator to properly decode a UTF-8 bytestream.
The problem is that the readUTFBytes and readMultiByte methods of an
ActionScript ByteArray don't treat 0x00 correctly. They return
a string that ends at the first 0x00, but the index into the ByteArray
has been advanced by however much you requested.

This is very silly for two reasons: ActionScript (and Javascript)
strings can contain 0x00 (they are not null terminated) and second,
UTF-8 can legitimately contain 0x00 values. Since UTF-8 is not
constant width there isn't a great way to determine if those methods
in fact did encounter a 0x00 or they just read the number of bytes
requested.

Doing manual decoding using readUTFByte one character at a time slows
things down quite a bit. And to top it all off, those methods don't
support the alternate UTF-8 encoding for 0x00 ("\xc0\x80"). They also
just treat that encoding as the end of string too.

So to get around this, for now I'm encoding zero as 256 ("\xc4\x80")
and then doing mod 256 in Javascript. Still doesn't result in much
benefit in firefox.

But, it's an interesting approach that could use some more exploration
so I'm leaving in the code in both places.

The purpose of the code is to be incorporated into other web projects
(whether those are free or not). AGPL prevents combination with other
HTML and javascript that is under a weaker (or proprietary) license.
Better would be a lesser AGPL, but there is not GNU standard for that.
So LGPL-3 meets most of my requirements. If somebody modifies the
actual client code and conveys it, then they must release the changes
under LGPL-3 also.

Add some implementation notes in docs/notes.