CMake builder

This patch adds an interface for defining “recipes”, which are
instructions for building a package from source.  It also provides an
implementation of this interface for building projects that use CMake.
There are test cases that verify that the expected commands are
executed, but this isn't linked into the `buzzy` command-line program
yet.
buzzy raw build

This patch adds the `buzzy raw build` command, which builds a package
whose source code is in the current directory.  Like the `buzzy raw pkg`
command, you have to provide all of the necessary package configuration
variables explicitly on the command line, including the `builder`
option, which selects which builder implementation is used to actually
perform the build.
CMake builder depends on cmake package

The CMake builder now automatically includes a prereq action that makes
sure that CMake is installed.
Refactor built package interface

This patch consolidates a couple of different parts of the API that are
used to build packages from source.  There are now three orthogonal
interfaces that together tell Buzzy how to build and install a package
from source: an “unpacker” (which doesn't exist yet), a “builder”, and a
“packager”.  There's also now a standardized design for the builder and
packager — they're basically just a collection of two or three actions
that perform the real work.

There are currently two available builders (noop and cmake), and two
available packagers (noop and pacman).  We autodetect which packager to
use, based on the distribution that the current machine is running.
Eventually we'll also autodetect a builder by inspecting the package's
source tree.
Detect errors when generating action messages

Several action `method` methods grab configuration values for the
current package.  Since this can fail, we need to be able to return
error codes.
Consistent results with non-forking test cases

The check framework usually runs each test case in a separate process,
so that it can test for segfaults without affecting the harness process.
You can override this behavior with the `CK_FORK` environment variable.
We do that sometimes during our valgrind tests to reduce the number of
crufty false positives.  But, we were being too aggressive with some
caching, which meant that the expected test case results didn't line up
if we weren't starting with a fresh empty process each time.  This patch
removes some of that caching (since it's not like the underlying
operations are very expensive), so that we can have more reproducible
test cases.
Use strings in file manipulation functions

Before we were constructing `cork_path` objects by hand before passing
them in to the various file manipulation functions.  But now we use
interpolated values for everything, and it's easier to just grab the
value as a string and pass that in.  Let the helper functions worry
about creating the `cork_path` and `cork_file` objects when they're
needed.
Merge branch 'feature/cmake' into develop

* feature/cmake:
  Use strings in file manipulation functions
  Consistent results with non-forking test cases
  Detect errors when generating action messages
  Refactor built package interface
  CMake builder depends on cmake package
  buzzy raw build
  CMake builder