Base paths for value sets

You can now provide a “base path” for each of the value sets in an
environment.  If you use `bz_env_get_path` to retrieve the value of an
environment variable, and the value set that provides the value has a
base path set, and the content of the variable is a relative path, then
we'll automatically concat the two together before returning the result.
We're going to use this in our filesystem repositories, so that we can
correctly interpret any relative paths mentioned in a YAML configuration
file.

(Note that a base path is a property of a value set, not of the
environment as a whole.  That's because we might have environments that
consist of several value sets, each of which is defined in a different
place, and which therefore should have a different base path.)
YAML environments

This patch adds functions for loading in an environment value set from a
YAML file.  The YAML file must contain a top-level mapping node.  We
currently only support looking for bare string keys in that top-level
mapping.  When we find a value in the YAML file, it must currently be a
string.  We assume that the string is an interpolated value, so you can
put ${var} references in the YAML content.  We might eventually support
additional kinds of YAML values (probably based on tags, which would
then be used to instantiate different value providers).  Soon we will
also support nested mappings in the YAML, with environment variables
with names like `a.b.c` being used to delve deeper in to the YAML
content.
Nested YAML environments

We can now read environment variables such as `a.b.c` from a collection
of nested mappings in a YAML file.  To read `a.b.c`, for instance, you
now need a YAML file that looks like:

    a:
      b:
        c: value
Cache values in YAML environments

The YAML value set implementation now caches any variables that you
retrieve from the YAML file.  This gives us a slight (but probably not
noticeable) speed boost when we read the same value from the YAML file
multiple times.  More importantly, it means that we don't have a memory
leak, since the value set is responsible for freeing any values that it
returns.  (Before, we weren't keeping track of the value instances at
all, so we never had a chance to free them.)
Repositories

This patch adds an interface for “repositories”, which are collections
of package definitions and any other related objects.  The most common
repository will come from looking for a `.buzzy` subdirectory somewhere
near the current working directory; this is how you build a package from
within its source checkout, presuming that the source tree includes a
Buzzy package definition.  Other repositories will come from “links”
defined in this default repository.
Hide phases with no actions

The `bz_action_phase_perform` function now takes in a flags parameter
that lets you control how it works.  The new `BZ_ACTION_HIDE_NOOP` flag
will cause us to not print out any messages if there aren't any actions
to perform in the phase.  Without this flag, we'll print out the header
message and a "Nothing to do" message.
Repository registry

The function that loads in a filesystem repository from the current
directory now add the repository to our new repository registry.  The
`buzzy info` command now prints out the location of each repository in
the registry.  This is how we'll support linked repositories in the
future.

The `buzzy doc` command now loads in the repository registry, too, and
uses the “main” (i.e., current directory) repository, if there is one,
when printing the value of an environment variable.
Packages no longer contain dependencies

A package exists on its own, independent of whatever dependency caused
us to try to build or install it.  Seems reasonable, right?
Package management commands

This patch adds the `buzzy build`, `buzzy test`, and `buzzy install`
commands.  These commands all take in a list of dependencies on the
command line, finds a set of packages that satisfies all of the
dependencies, and then performs the desired action for each of those
packages.
Default built packages in filesystem repos

Repositories can now define a “default package”.  If the repository is
loaded because you execute buzzy from within its directory, and the
repository defines a default package, then that package will be used if
you don't provide any dependencies to the `buzzy build`, `buzzy test`,
and `buzzy install` commands.

A filesystem repository will define a default package if its .buzzy
directory contains a package.yaml file.  The `source_path` variable for
this default package is set to point at the repository's base path —
i.e., the directory that contains the repository's .buzzy directory.
(This can be overridden by setting `source_path` directly in the
package.yaml file.)

We don't yet auto-detect as much as I would like, but you can now build
a package if you set some variables explicitly.
Default verbosity for building packages

We now default to verbose output when building, testing, and installing
the packages specified on the command line for the corresponding `buzzy`
commands.  We still default to non-verbose output for any prereqs that
we decide to install ourselves.
Create package destination directory

Otherwise we get an error when trying to build the package.
Print non-verbose output when error occurs

Before, in non-verbose mode, our helper function for running a command
would just drop the stdout and stderr output.  We now collect it into a
buffer, so that if there's an error running the command, we can tell the
user why.
Detect CMake packages

We now automatically detect when a source package uses CMake, and set
the `builder` variable to `cmake` accordingly.  The detection logic
isn't outrageously complicated — we just look for a CMakeLists.txt file
in ${source_path}.
git version strings

This patch adds a function for converting a version string obtained from
`git describe` into a Buzzy version string.
Default value for `version` in git repositories

If the repositories that defines a source package is a clone of a git
repository, we now add a default value for the `version` variable which
parses the output of `git describe`, on the assumption that you're
creating tag names that include the latest released version number.
(The standard `git describe` output for describing commits after a
release tag produce Buzzy `+gitXXXXXXX` postrelease versions.)
Add buzzy package description

Buzzy now has its own Buzzy package description.  You have to bootstrap
some version of Buzzy by hand, but once you do, you can use Buzzy to
produce a binary package.
Reorganize package work directories

We now put the work directories for each package into
${work_path}/packages, so that they're nicely segregated from the other
top-level directories in the Buzzy cache path.
Merge branch 'feature/repo' into develop

* feature/repo:
  Reorganize package work directories
  Add buzzy package description
  Default value for `version` in git repositories
  git version strings
  Detect CMake packages
  Print non-verbose output when error occurs
  Create package destination directory
  Default verbosity for building packages
  Default built packages in filesystem repos
  Package management commands
  Packages no longer contain dependencies
  Repository registry
  Hide phases with no actions
  Repositories
  Cache values in YAML environments
  Nested YAML environments
  YAML environments
  Base paths for value sets