Always check expected commands and actions

I've factored the assertions that verify which actions and commands were
executed into the test case superclass, so that they're always run.  Now
you just need to set the `expected_actions` and `expected_commands`
arrays in the test case, and they'll be checked for you.
Git repositories

This patch adds a helper class for checking out a git repository.  If
you don't specify a destination for the local clone, it creates a
pathname based on the repo's remote URL.
Git environments

This patch adds a new FilesystemEnvironment subclass that downloads the
environment files from a remote git repository.
Better support for multiple “rounds” of actions

Before, we assumed that Buzzy would collect together all of the Actions
that would need to be performed, and then execute them all in one go
(using the `buzzy.action.perform_all` function).  It turns out that some
actions will need to be performed before we can determine the full set
of other actions to perform.  (For instance, we have to clone a git
environment before we can look in that environment to determine what to
do.)

So, now there's a `perform` method directly on the Action class that you
can call whenever.  I had to refactor some things to make this work;
some bits of state that we used to only calculate within `perform_all`
now need to be maintained across multiple calls to `perform`.

We still assume that at some point we'll calculate a final list of
actions to perform.  Once you've done that, you should call `count` on
those actions before performing them.  This makes sure that we still get
the nice `[XX/YY]` prefix before each status message, giving the user
feedback about how much work we're going to have to do.  For the
“initial” actions, you don't need to call count; their status messages
will just have a `[XX]` prefix, indicating that we don't know the total
amount of work yet.
CMake builder

This patch adds a helper class that can build a CMake package.  You must
provide the name of package, and several optional configuration
parameters.
Allow empty actions in pre- and postreqs

An Action instance can now include `None` in its list of pre- and
post-requisites.  These will be silently skipped.  This makes it easier
to add the results of an action retrieval function to a prereq list,
since you don't have to verify that you got an actual action first.
Rename packager to package database

Man, how many times am I going to rename this stuff?  “Packager” implies
that it creates packages, whereas it really just knows how to install
them.  (It might also create the package, but it doesn't have to.) We're
about to introduce a “recipe database”, which contains instructions for
building source code, so “package database” is a nice analogue.
Remove operation from Dependency

Dependencies no longer include the operation that you want to perform;
they just include the package name and requested minimum version.
Building packages from a recipe

This patch adds a number of new moving pieces, which together let you
build a package from source.

A “recipe” consists of a collection of “steps” — currently source,
build, and stage.  These steps define how to download the source code to
a package, build that code, and stage the results into a fake
installation directory.  Each environment can now provide a list of
recipe databases, just like the list of package databases that they
already provide.

That on its own isn't enough to install a built package.  There will be
distro-specific rules for creating an actual package file from the
staged build artefacts, and then for installing that package.  The Arch
Linux environment, for instance, defines a new package database that
checks whether there is a recipe for a package, and if so, uses the
recipe to build the package, and then packages and installs it.  (Or at
least, it will; right now it just does the build step.)

Recipes are separated out from the packaging and installation logic
since building the source code doesn't really depend on how it's going
to be packaged and installed.  Or at least, it doesn't *completely*
depend on that.  There are some details of the packaging and
installation logic that do inform the build steps.  Right now, this
includes the installation prefix that the code will be installed into;
you need that during the configure step of most build systems.  To keep
the clean recipe/package distinction, we put these details into a “build
context”, which recipes are allowed to query as part of constructing the
build actions and steps.
Default dependencies

Environments can now specific a “default dependency”.  If the user
doesn't provide any package names on the command line (for those
commands that take in a list of packages, of course), then we'll perform
the operation on the default dependency.  This will let you just run
`buzzy build` from within a Buzzy-enabled git repository to build that
repository's package.
Auto-detect package version from git repo

A lot of projects use git tags to mark version in the project's git
repository.  That lets us use `git describe` to automatically detect the
project's current version, rather than requiring the project developers
to hard-code the version number in the package.yaml file.
`buzzy test` command

You can now test packages as well as build and install them.  Our CMake
builder will automatically run the `make test` target to test packages
built that way.  To implement this, I refactored some of the recipe
building code: there's now a `Recipe` class that collects all of the
information and actions needed to build a package.
Merge branch 'feature/builders' into develop

* feature/builders:
  `buzzy test` command
  Auto-detect package version from git repo
  Default dependencies
  Building packages from a recipe
  Remove operation from Dependency
  Rename packager to package database
  Allow empty actions in pre- and postreqs
  CMake builder
  Better support for multiple “rounds” of actions
  Git environments
  Git repositories
  Always check expected commands and actions