Switch to libossp-uuid, to get UUIDs on Windows

This was only used to avoid a necessary check in collab builds on
Windows. @jtanx, who does the Windows binaries, says collab currently
isn’t building on Windows anyway.
This is more correct. I had 40 there to cover other methods of id and serialization (and because 8 bytes on a beacon isn't the end of the world). I hadn't changed it down to preserve maximum cross FontForge version compatibility.

It will cause a FontForge version break as of when you merged the code because the username and machinename fields will have moved 7 bytes back now in a  beacon_announce_t message. So all fontforges before yesterday will be able to read each other's beacons, and all fontforges today onwards will work with each other, but those two sets of builds will not be happy with each other's beacons.

Beacon publication uses a binary structure which is assumed to be the same on the send/recv side.
https://github.com/fontforge/fontforge/blob/master/fontforgeexe/collab/fontforge-internal-collab-server.c#L259

A handful of lines back from the above link you'll see "ba.version = 2" which is the first (and thus magic numbers etc) version of the versioning integer that I included in beacon_announce_t to allow for evolution of the binary structure over time without breaking cross build version compatibility. This is also why ba.version is located as the second element in beacon_announce_t.

I suppose we could use protobufs, xml, json, marshal-lib-foo or indeed use czmq to create a packet from the atomic elements and use czmq to (de)serialize that to avoid express byte layouts. For one simple structure like this it seemed simpler to not go that far yet.