Add Gamepad Support via GLFW

[geringsj]

Publishes Gamepads provided by GLFW as frontend resource. This opens up the possibility to control parts of MegaMol via controller (e.g. View3D, Clipping Plane, etc). The new Exotic Inputs Service is supposed to grow up to feed Gamepad Inputs into MegaMol Graph Modules, e.g. for View3D Camera control.

Summary of Changes

• Pulls Joystick/Gamepad state from GLFW
• If a Joystick provides a Gamepad layout mapping via GLFW ("is a XBox-like gamepad"), publishes that Gamepad as a resource
• Exotic Inputs Service shows GUI Window with current Gamepad states

References and Context

Gamepad controlls are an approach to make manipulation of the Clipping Plane Pose suck less. Also may be cool in general, e.g. on Powerwall or other MegaMol PR stunts/demos.

TODOs

• Need general approach to manipulate Pose of objects in MegaMol (Camera Pose, Dataset Pose, Clipping Plane Pose) in all the different ways (Arcball, First Person, ...)
• Map controller axes/buttons to Graph Parameters like the Command Service/Hotkey Editor does? How cool is that.

Test Instructions

Start MegaMol and connect your controller. Look at controller state in GLFW Gamepads window.

[invor]

So the idea is that controller input does not use the same call-based propagation as mouse and keyboard with callback functions (OnMouseButtonCallback etc.)?
Mapping controller inputs directly to parameters sound interesting, but some actions require additional context and manipulate more than a single value at once, e.g. orbital camera movement. A generalized concept for pose, including local and global space transforms, could help but mostly to make different implementations look more alike I guess.

[geringsj]

I guess the current On*Callback solution is kind of awkward, I would argue it puts the wrong kind of responsibility on the graph modules. I would like to abstract away the raw input source and think in 'actions' or 'commands' for the graph which are resolved before graph execution. So you could map different input sources to the 'action' of rotating the camera or moving a clipping plane.

Regarding actually using the controller inputs as envisoined, I think it would require to pull the camera controller out of the view into the frontend in some form. Seemed too much work for the gamepad inputs prototype.