Draft: Add XfwMonitor abstraction and "Move to Monitor" submenu

The initial impetus for this was to add a "Move to Monitor" submenu for XfwWindowActionsMenu (backed by a new xfw_window_move_to_monitor()). But I quickly learned that naming monitors in the menu is more than just calling the appropriate functions on GdkMonitor, as the names there are not very friendly.

I looked at how xfce4-display-settings did it, and there was a bunch of code that it seemed silly to copy. After some discussion, it seemed to make sense to move the monitor friendly-name code to a shared library. But what we will eventually need is a full monitor configuration abstraction to replace the XfceRandr stuff in Display Settings, so: XfwMonitor (XfwMonitorX11 will essentially be a refactored version of XfceRandr). This is the start of that, though it doesn't actually do anything yet: aside from the monitor friendly-name stuff, all it does is wrap GdkMonitor.

One thing to note: the EDID code in display settings not only parses a pnp.ids file on the local filesystem, but it has a hard-coded copy in the binary that is modified to remove suffixes like ", Inc.", "Pty Ltd", etc. from the vendor names, since they aren't useful for a display name and just take up space. It looks like the hard-coded copy adds some ID mappings that perhaps weren't in the old-old-old copy of pnp.ids that this copy was based on, but have since been added (and then some). Instead of including this old hard-coded copy, I've left it out, and I've written some code to strip some common unneeded suffixes from the pnp.ids file that the library reads from the filesystem. This does mean that the user must have the hwdata package (at least that's what it's called on Debian) installed. I think that's fair to require, and not provide a hard-coded fallback (which is a pain to maintain, and quickly becomes out of date).

Interestingly, while on X11, gdk_monitor_get_manufacturer() returns the 3-character vendor ID code, on Wayland, it appears to return a full manufacturer name (so we don't need to use this mapping file at all). I'm not sure if this is universal, though, or if it's specific to wlroots-based compositors, or even just is a special feature of Wayfire itself.

Closes #10.