This was causing deadlocks all over on Windows. Now things seem to be
running smoothly!

This is necessary for URBs which synchronously complete. This is common on
the win32 backend.

The hotplug branch in manuelnaranjo's repo has very broken support for
composite devices, blah. So let's switch back to libusbx master and deal
with that.

This is pointed to a bleeding-edge branch where Windows hotplug support is being developed

This is more secure by default, and it allows fcserver to work correctly on Mac OS when no networking is available. (With wifi disabled, a server bound to 'null' won't be listening on localhost. Blah.)

When staring directly at the LEDs, the dithering flicker is visible- but in an enclosure, the flicker is totally nonexistent and the linear section causes a noticeable discontinuity.

A pure nonlinear-only approach seems like the best default. I'll document cases when this linear section might help, and it will be up to individual clients (or fcserver config files) to enable it.

This is really dumb, we weren't processing backlogged packets from the opcsink buffer. This is the cause of the ugly delays I'd been seeing in the 'waves' demo.

This lets us disable the Nagle algorithm, and have finer control over error handling