The previous implementation was hard to follow and maintain. Instead of
doing intentional rounds trips, we use now a two way approach. GUI is
automatically forwarding remote actions by calling "callHotkeyActionRemotely"
through DBus. Core on the other hand, emits a signal "remoteHotkeyAction"
that is processed in a different function in GUI.
On both sides, actions from the same local machine are filtered.
ref T402
The main reason why CInputManager was singleton is the easy access across
the code. That had the negative side effect that time of destruction was
at a very late stage of the shutdown and could not be controlled by us.
My moving it to CApplication, the access is equally easy (using sApp) and
allows to be cleaned up properly during graceful shutdown.
ref T391
Every first call to CInputManager::instance() was automatically creating
the low level input devices. This was not always desired and therefore
creation is now explicit via function.
Unit tests do not need the devices created. In contrast, Windows unit tests
failed since Windows didn't like the Jenkins service childs to allocate
DInput devices.
T391
If they are released with the deallocation of CInputManager, we might
run into global deallocation hell.
Also on Windows release all DirectX devices before COM library is closed.
ref T391
* standard paths for applications
* support for Qt::DecorationRole
* QMap<QString, QPixmap> m_availableActions
* Constructor for icon only
* only leafs support actions
