build: Replace build system with CMake

This patch replaces the previous build system (based on Ninja files
generated from a Python script) with CMake.

For a quick walk-through, see `HACKING.md`.

I have tested this build system with all combinations of:

- GCC
- CMake 3.5.2 and CMake 3.11.2

The most important characteristic of this new build system is how
dependencies are handled.

Previously, dependencies of Seastar that were not readily available as
system packages were included as Git submodules and compiled as part of
the generated `rules.ninja` file.

In this system, we specify with CMake the names and versions of all
dependencies, but we do not bundle them in the build itself. In this
way, the dependencies can be supplied from arbitrary sources. These
could include system packages, custom locations on disk, or package
managers like Conan.

`configure.py` and `test.py` still exist and should be functionally
compatible, but now wrap the CMake-based replacements. Options which are
not supported in the new build system are not included in those scripts
any longer.

Git submodules still exist for `fmt` and `dpdk`, but a consumer of
Seastar can provide these from other sources and instruct CMake on how
to find them if they wish.

One option for supplying dependencies included in this patch is the
`cooking.sh` script, part of the `cmake-cooking` project. This script
creates a local development environment containing all (or some)
dependencies by fetching their source code, compiling them, and
installing them into a project-specific location. More instructions for
using `cooking.sh` are available in the new `HACKING.md` file and on the
project's home-page.

The most convenient way to build the external dependencies included as
Git submodules is to use `cooking.sh` with the `dev` recipe (which
points to them) or to use the compatibility configure script:
`configure.py` (which also uses `cooking.sh`, but only for the
dependencies included as submodules).

Because the build system only checks that dependencies are satisfied,
when Seastar is installed via -- for example, `ninja install` -- the
installed files are relocatable to any system which includes the
dependencies and for which the installation destination exists.

As part of this build system, we also generate a pkg-config
specification which is installed alongside the CMake files necessary for
consumers to use Seastar.

This new build system also includes the new `test_dist` target. This
test verifies that clients can build applications against Seastar with
the files that the build-system installs. The test uses `cooking.sh` to
manage all dependencies and checks both "native" CMake support and also
compilation with pkg-config.

Finally, Doxygen needs to be instructed on how to output files based on
the way the build is configured. These changes are reflected in a new
template file (`Doxyfile.in`) and configured by the build system.

Fixes #67.
Fixes #264.
Fixes #313.

Signed-off-by: Jesse Haber-Kucharsky <jhaberku@scylladb.com>
Message-Id: <67178984d629d3f9acb16f8424da2a732daf75c8.1543507802.git.jhaberku@scylladb.com>

.gitignore

@@ -5,3 +5,4 @@ build
 build.ninja
 cscope.*
 __pycache__/
+cmake/Cooking.cmake