noVNC was never processing more than one framebufferUpdate message per
onmessage event. If noVNC receives an incomplete framebufferUpdate and
then receives the rest of the framebufferUpdate plus another complete
framebufferUpdate, then it will fall permanently behind.

If there is more to process after a completed framebufferUpdate, then
execute normal_msg again.

All the render routines must return false if there is not enough data
in the receive queue to process their current update, and true
otherwise.

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).

Interestingly, the bug depends on compiler behavior. If local
variables are automatically initialized to 0, then this always caused
the program to error out indicating a failure to parse the listen
port. Otherwise, the test was a no-op (except the rare case where the
memory happened to be zero anyways).

Thanks to Eugen Melnikoff for finding this.

The listen port should be opened before daemonizing otherwise if
opening the port fails, the user will get no feedback. The only
complication was that the listen socket needs to not be closed as part
of daemonizing.

Thanks to http://github.com/rickr for finding it.

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.

Interestingly it turns out that using the native base64 routines does
not improve performance. Likely because the actual time is in
marshalling/unmarshalling between strings and arrays (and associated
garbage collection overhead) which has to be done either way.

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

mootools is no longer needed. The bug that the FABridge test was
testing has been resolved in web-socket-js so it's no longer needed.

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

Also, move bugs from TODO to github issues.