Crouton in a tab

Still a few issues to iron up, more testing, and a few missing features, but the general idea is there.

Known issues:
 - The extension does not start with focus (you need to click, this might be a Chromium OS bug)
 - IME events (place holder is there, needs implementation)
 - Caps lock is not synchronized (https://github.com/dnschneid/crouton/pull/1144#discussion_r19914500)
 - Waiting for extension to connect before starting WM is potentially racy (the setres 1024 768 trick to provide xfce with a reasonable DPI fails as the extension starts too soon)... (actually, this is more of a xorg+dummy bug: we could get rid of that if dummy supported xrandr 1.2)
 - On stable channel (`6158.70.0`), the extension/Chrome sometimes crashes on disconnect (fairly frequently): clearly a Chrome bug. Never seen that problem on canary.

Review entries pending:
 - Logging: https://github.com/dnschneid/crouton/pull/1144#discussion_r19862772
 - Super_L: https://github.com/dnschneid/crouton/pull/1144#discussion_r19866490

Fixed:
 - Touch events (basic, single point only)
 - Window title should correspond to chroot name
 - A leftover FIXME in the code, we should force croutoncycle instead of removing files
 - Errors when loading NaCl module are not reported
 - Limit number of resolution changes when resizing (it's slow because we send far too many "R" requests)
 - Move the websocket functions into a common file
 - Rename Nacl module/target to Kiwi/xiwi.
 - "Error target STRING not available" sometimes appears during switch (harmless, probably due to old chroots running)
> This should probably be a checkbox for those that prefer having the super/ctrl/whatever key.

Currently, Chromium OS settings are obeyed. If you swap Search and Ctrl in Chromium OS, Ctrl will act as Search/Super_L (so Ctrl+Left = Home), and Search as Ctrl.

Allowing different settings in Chromium OS/crouton would only lead to confusion (particularly when it comes to Search+arrows keys).

> Alternatively/additionally, should pressing and releasing it without any other key in the middle trigger press+release events for Super_L?

Agree, that should be an easy fix.

> I think we're generating too many super_l events. Can we combine adjacent generated release+press events?

Yes, the logic is simplistic, but it works. I'll have a look. If the extra logic is not too complicated, I'll implement.