make it easier to dump / load / sync monitor geometries

[totaam]

The client already does this during the initial packet exchange, we should be able to dump the monitor data to a JSON file and add a server command to apply it to the X11 server (and eventually other backends).
This could even be extended to include a monitor-sync command that does this to a remote host.

If this is done properly, the server should figure out that the geometry is the same and leave it unchanged.

We could also support a default vfb config, maybe just using --resize-display=/path/to/monitors.json
(adding a GUI for it may be a step too far)

[totaam]

Usable as of 0b64093.
Example:

xpra_cmd.exe monitor-info E:\monitor.json

Then transfer the monitor.json file created to the server and run:

xpra set-monitor :10 monitor.json

The arguments are:

• the DISPLAY to connect to, which defaults to $DISPLAY - optional on MacOS and MS Windows
• the file to save to / load from (ie: monitor.json) - the commands also support - (stdout / stdin respectively) and the set-monitor subcommand also supports providing the whole json data as a string argument

---

Here is an example file from a MS Windows 10 VM:

{
	"0": {
		"primary": true,
		"geometry": [
			0,
			0,
			1280,
			1094
		],
		"refresh-rate": 64000,
		"scale-factor": 1,
		"width-mm": 339,
		"height-mm": 289,
		"manufacturer": "(Standard monitor types)",
		"model": "Generic Non-PnP Monitor",
		"subpixel-layout": "unknown",
		"workarea": [
			0,
			0,
			1280,
			1054
		]
	}
}

(the refresh rate unit is multiplied by 1000: 64000 is 64Hz)

This results in the following randr configuration:

$ DISPLAY=:10 xrandr  | egrep "\*|mm"
DUMMY0 connected primary 1280x1094+0+0 339mm x 289mm
   1280x1094@64  64.00* 

[totaam]

This subcommand may also be useful to verify DPI / win32 issues.
As per #697 (comment) : It might be a good idea to completely bypass GTK for display detection : #921
DPI_AWARE / DPI_AWARENESS: c76a74d / #3943

[totaam]

The randr bindings needed some fixes recorded in #4744