Use XRandR and Xinerama to get display info

[randomnine]

Fixes fullscreen behaviour on multiple-monitor systems under Linux.

On Linux, default X11 behaviour seems to describe multiple monitors as a single virtual display (stretched across all physical monitors), so for example it might describe a pair of 1920x1080 monitors as a single 3840x1080 display. Full-screen SDL windows will therefore attempt to cover that 3840x1080 area and stretch across all displays instead of expanding to a single physical screen as they do on Windows and OS X.

SDL_x11modes.c appears to rely on XRandR (or possibly Xinerama) to get information on distinct screens within that virtual display. After enabling both here, fullscreen windows in Linux correctly take full screen on a single monitor.

Compiling with this change requires packages libxrandr-dev, libxinerama-dev and a clean build (when built as part of Lime, at least).

[ruby0x1]

can you shield these against a NATIVE_TOOLKIT_SDL_X11_XRANDR define (possibly one for each specific change added) - breaking the default build by third party dependency is not ideal

[randomnine]

As in, off by default, and requiring a define to enable? Or on by default, but configurable?

For what it's worth, my experience of this was that fullscreen modes would silently break on some Linux systems in my OpenFL game (showing only half the window) and there was no reasonable way to detect when it would break or work around it. It took me several hours to track it back to this, and I'd like to help others get fullscreen that works by default instead of having the same trouble.

[ruby0x1]

OpenFL (or whichever framework is including this library) must configure the build against their required dependencies and defines.

The point of native-toolkit libraries is to keep the libraries central, having the defines be on by default adds build dependencies, so they must not be enabled by default.

To be more clear: off by default.
The flag is enabled by the define, set in the xml file of the user (read as:openfl),
before it includes the native-toolkit files.xml dependency.

This is how it works with the native-toolkit libraries.

(To add: having the flag and having the ability to configure it to just work is a great thing! Merging the PR will just require it conform to the patterns defined by native-toolkit libs)