Plug new keyboard handling into input.js (which breaks everything else), and update input.html to work with this

First crack at supporting touch screen for devices like Android and
iOS tablets. Part of https://github.com/kanaka/noVNC/issues/48.

This change detects touch screen support and uses the touchstart,
touchmove, touchend events in place of the normal mouse events.

In order to support middle and right mouse clicks, if the device is
a touch device, then three toggle buttons are added to the UI
representing the left, middle and right mouse buttons. These select
which mouse button will be sent when the screen is touched. All the
buttons can be toggled off, in which case then the touch events only
move the mouse cursor rather than sending a mouse down and mouse up
for touchstart and touchend events respectively. This allows fairly
full control with the mouse on touch screens.

This is part of addressing issue #21 - non-US keyboard layouts.

There are several challenges when dealing with keyboard events:
  - The meaning and use of keyCode, charCode and which depends on
    both the browser and the event type (keyDown/Up vs keyPress).
  - We cannot automatically determine the keyboard layout
  - The keyDown and keyUp events have a keyCode value that has not
    been translated by modifier keys.
  - The keyPress event has a translated (for layout and modifiers)
    character code but the attribute containing it differs. keyCode
    contains the translated value in WebKit (Chrome/Safari), Opera
    11 and IE9. charCode contains the value in WebKit and Firefox.
    The which attribute contains the value on WebKit, Firefox and
    Opera 11.
  - The keyDown/Up keyCode value indicates (sort of) the physical
    key was pressed but only for standard US layout. On a US
    keyboard, the '-' and '_' characters are on the same key and
    generate a keyCode value of 189. But on an AZERTY keyboard even
    though they are different physical keys they both still
    generate a keyCode of 189!
  - To prevent a key event from propagating to the browser and
    causing unwanted default actions (such as closing a tab,
    opening a menu, shifting focus, etc) we must suppress this
    event in both keyDown and keyPress because not all key strokes
    generate on a keyPress event. Also, in WebKit and IE9
    suppressing the keyDown prevents a keyPress but other browsers
    still generated a keyPress even if keyDown is suppressed.

For safe key events, we wait until the keyPress event before
reporting a key down event. For unsafe key events, we report a key
down event when the keyDown event fires and we suppress any further
actions (including keyPress).

In order to report a key up event that matches what we reported
for the key down event, we keep a list of keys that are currently
down. When the keyDown event happens, we add the key event to the
list. If it is a safe key event, then we update the which attribute
in the most recent item on the list when we received a keyPress
event (keyPress should immediately follow keyDown). When we
received a keyUp event we search for the event on the list with
a matching keyCode and we report the character code using the value
in the 'which' attribute that was stored with that key.

For character codes above 255 we use a character code to keysym lookup
table. This is generated using the util/u2x11 script contributed by
Colin Dean (xvpsource.org).

API change: for intergrators that explicitly include the Javascript
files (that do not use include/vnc.js)js, include/input.js is a new
file that must also be included.

The mouse and keyboard handling could be useful on its own so split it
out into a Keyboard and Mouse class in include/input.js.

This refactoring is preparation to deal with issue #21 - non-US
keyboard layouts.

Fix mouse button mapping in IE9. All browsers have converged on
a standard left=0, middle=1, right=2 ... all except IE that is.

Add html5 doctype to tests.

In vnc_perf test, use do_test instead of start for function name since
start is a keyword in IE.

In error about Flash give a link to Adobe's download page.

This allows tests to work on the github pages site.

Rename the $() selector to $D() so that it doesn't collide with
the jQuery name.

The API change is that the 'target' option for Canvas and RFB objects
must now be a DOM Canvas element. A string is no longer accepted
because this requires that a DOM lookup is done and the Canvas and RFB
should have no UI code in them. Modularity.

 - util.js that contains essential functions
 - webutils.js that contains the GUI utility function.js

this helps to include noVNC in other project, especially Cappuccino Application
i

New API:

To use the RFB object, you now must instantiate it (this allows more
than one instance of it on the same page).

    rfb = new RFB(settings);

The 'settings' variable is a namespace that contains initial default
settings. These can also be set and read using 'rfb.set_FOO()' and
'rfb.get_FOO()' where FOO is the setting name. The current settings
are (and defaults) are:
    - target: the DOM Canvas element to use ('VNC_canvas').
    - encrypt: whether to encrypt the connection (false)
    - true_color: true_color or palette (true)
    - b64encode: base64 encode the WebSockets data (true)
    - local_cursor: use local cursor rendering (true if supported)
    - connectTimeout: milliseconds to wait for connect (2000)
    - updateState: callback when RFB state changes (none)
    - clipboardReceive: callback when clipboard data received (none)

The parameters to the updateState callback have also changed. The
function spec is now updateState(rfb, state, oldstate, msg):
    - rfb: the RFB object that this state change is for.
    - state: the new state
    - oldstate: the previous state
    - msg: a message associate with the state (not always set).

The clipboardReceive spec is clipboardReceive(rfb, text):
    - rfb: the RFB object that this text is from.
    - text: the clipboard text received.

Changes:

- The RFB and Canvas namespaces are now more proper objects. Private
  implementation is no longer exposed and the public API has been made
  explicit. Also, instantiation allows more than one VNC connection
  on the same page (to complete this, DefaultControls will also need
  this same refactoring).

- Added 'none' logging level.

- Removed automatic stylesheet selection workaround in util.js and
  move it to defaultcontrols so that it doesn't interfere with
  intergration.

- Also, some major JSLinting.

- Fix input, canvas, and cursor tests to work with new model.

Now working under Arora 0.5.

But not Konqueror 4.2.2 (WebSockets never connects).

IE support with excanvas still pending.

On path towards removing dependency on mootools in non-UI code.