USB and serial devices support, Win32, CMake

[ruevs]

Implement support for pretty much all 3Dconnexion 6DOF controllers - USB and serial.

Win32: Add Windows example.

CMake build system.

[jtsiomb]

Thank you for your contribution, but I can't merge this as it stands for a number of reasons:

1. libspnavdev, as you can probably tell by the fact that pretty much nothing was implemented before your pull request, is not active at this stage. The idea was to move all the device handling code from spacenavd to libspnavdev, to make it usable without spacenavd by standalone applications, and then change spacenavd to use libspnavdev for device handling. This was never done. The device handling code is still in spacenavd.
2. As a result of 1, this pull request duplicates much of the work spacenavd already does.
3. None of the decisions were discussed with me, leading to changes I cannot accept, like using cmake.

There are three ways forward that I can see:

1. Make any applicable additions (like adding an alternative USB backend using hidapi, and adding windows serial support, or whatever else is relevant) to spacenavd instead. This should be done as a series of narrow pull requests, one feature at a time, and after discussing integration with me first, through an issue, or through email.
2. If you're not interested in spacenavd but rather only on 6dof device handling as a standalone library: I could prioritize moving the spacenavd device handling core into this library, and then get back to you when that's done, so you can again submit a series of narrow pull requests merging relevant parts of your code into it.
3. If you don't want to get involved with either 1 or 2, I could just cherry-pick changes from this pull request and merge to spacenavd at my leisure.

Let me know which way you prefer.

Edit: if you want to discuss any of this in real-time, I'm always idling in #spacenav on libera.chat (IRC) as "nuclear".

[ruevs]

It would have surprised me, if you had just merged this pull request. I created it only to replace my original three, since they are now obsolete - essentially to "let you know" of the current state of the code.

The work I did was out of curiosity how to communicate with space mice and your nascent libspnavdev looked as a perfect starting point.

As for the ways to continue:

1. I've not looked deeply into spacenavd - perhaps I should. Porting it to Windows could be interesting but I can not commit to this - too little time :-)
2. I would definitely participate in this. But I am in no hurry at all. Nothing critical depends on my code. As far as I am aware the only place it is (potentially) used is here Libspnavdev solvespace/solvespace#968 .
3. You are of course welcome to cherry pick any of the code I've written (and/or copy pasted from spacenavd) at any time. Both in libspnavdev and in spacenavd.

P.S. It has turned into a hobby of sniping cheap space mice just to test if they work correctly or to implement the support (I do realize I'm duplicating code from spacenavd but I thought this was the idea).

P.P.S. CMake is non-itrusive and is not necessary. You can completely ignore the commit adding it if you want.

[ruevs]

And of course I would be very glad if you give me specific comments and suggestions of what could/should be done differently or improved.

[jtsiomb]

Nice collection :)

Ok, in that case no worries, but it would be helpful if you have said what the pull request was about, because usually it's meant for contributions intended to be merged, so that's what I thought this is.

If you don't have the time to work on spacenavd, I think the best approach would be #2. I'll try to get it done soon and then I will be in a better position to discuss what to merge and how.