CMake support was added as an alternative to the pure Makefile that already exists. CMake supports generating build files for a large set of different platforms. Makefiles, XCode project, Visual Studio and so on...

The CMake project includes build rules for installing, including running the server as a daemon using SystemD.
Adding similar support for init would be possible as well.

CMake is similar to configure + autoconf, so it is possible to turn on and off different features before compiling.

The main reason for this change was to create an easily reproducible way to install the Fadecandy server as a daemon.

The target for these efforts was mainly the Raspberry Pi platform using the Raspbian distribution that uses Debian packages for installation. So this current implementation has focused on enabling building Debian Packages.
However CMake/CPack supports other installers for other platforms such as RPM, NSIS and OSX installers to name a few. Adding support for those wouldn't be hard.

Also to support the use case of running the server as a system daemon, I have also added a default config path that the fcserver tries to read under:
  /etc/fcserver/config.json

If no config is given on the command line explicitly, fcserver first looks here before using the default config.

To build using CMake (Tested to work on Raspbian and OSX):

```bash
mkdir build
cd build
cmake ..
make
make install  # Manual install (see below for debian package)
```

To list available CMake options:
```bash
cmake -LH ..
```

To build the debian package:
```bash
cpack -G DEB  # Must be done after build instructions above.
```

By default the debian package runs a post-installation script that will create a "fadecandy" user that the daemon is run under. This can be turned off using a CMake option.

Use negative count to map pixels in reverse order along
a strip.

LWS wasn't giving us the usual connection closed callbacks due to our early hijack of the connection. Instead, delete the buffer when we unregister the client's poll FD.

resolves #28

I'd been assuming that the OS always copied our USB transfer buffer at submit-time. Turns out that this is true for Linux but not for Windows or Mac. This caused tearing when fcserver received a new frame while previous frame(s) were still queued in the USB host controller.

Fixed this by copying to a per-transfer buffer on Windows and Mac. Linux is unaffected. We avoid performing an additional copy there.

If we issue a short write, libwebsocket handles it kinda ungracefully and we have no idea when to close the socket. Instead of letting libwebsocket copy our content into a temporary buffer, we can just give it smaller pieces.

This lets us uniquely identify a particular device connection instance.

This keeps the size of the fcserver binary down.

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.