A daemon to manage dock functionality on the Asus Transformer

Scope:
This project will initially be for the TF101, and can include the TF201 in the future, when more is known about the hardware, and root access is gained.

Design:
 * The software should be in 2 parts, a backend and a frontend. The backend will monitor the dock and take action according to settings that the user has configured. Having a frontend/backend architecture will allow for different frontends to be designed for the various desktop environments, GNOME/XFCE/LXDE, KDE, etc.
 * The frontend should manage all settings. Frontends can use whatever settings storage mechanisms they like, but GSettings should be encouraged.
 * The backend should provide an API for the frontend to display the current status to the user.
 * API design should be flexible such that a frontend can be written in many different languages. Dbus is the best IPC to use between the frontend and backend, so the API will be directly via dbus.
 * The daemon will not manage bluetooth/wireless/power, as there are already apps/applets to manage network and bluetooth, and better power support is planned for the Transformer kernel code.
 * The daemon will monitor dock connection/disconnection via libgudev, and act accordingly when the dock is connected/disconnected.
 * The frontend will automatically be loaded via the XDG autostart process, with a .desktop file in /etc/xdg/autostart. Settings can then be checked, and the frontend can act accordingly depending on whether the user wants the daemon to be started or not.
 * The daemon will be a service that is activated via dbus by the frontend.
 * Once the daemon has started, the frontend will register a callback with the daemon, to receive status changes from the daemon.
 * The daemon will run on the session bus.

Feature set:
Initial features for the transformer monitoring daemon:
 * Load an on-screen keyboard when the dock is not connected.
 * Show dock connection state in system tray/indicator area.
 * Allow a user to set their preferred on-screen keyboard.

In the future, it may also be worth considering only showing an on-screen keyboard when a text entry box/document edit view has focus. Determining this information would be possible by leveraging the emerging at-spi cross-desktop accessibility framework to query the currently focused widget.

Misc notes:
 * THe off state for the lid switch needs to be reversed.