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.

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.)

Configuration is now no longer mandatory.

Almost fast enough.. just 1.3ms more to shave off per frame.

Originally I wasn't planning on doing this, but since I need to reclaim some RAM anyway, might as well just start hacking out everything we don't need...