Convert Arch and Debian versions to Buzzy versions

We could already convert from Buzzy versions to the native version
numbers, but we'll also need the inverse conversion.
Refactor native packages

The Arch and Debian classes for installing a native package had a fair
bit of shared code, which I've factored out into a separate class.
Refactor built packages

Same kind of refactoring, but for built packages.
Build and install dependencies in recipes

You can now add `build_dependencies` and `dependencies` fields to a
recipe YAML file.  If present, Buzzy will make sure that all of those
packages are installed before trying to build the recipe.  We're not
adding those dependencies to the packages themselves yet, although all
the information is there so that it should be fairly easy to do so.
Update remote environments before reading recipe

If a filesystem environment refers to another remote environment, we
need to download a local copy before we'll be able to look through it's
.buzzy directory.  Without this, we won't actually see any of the recipe
descriptions in the remote environment.
Explicit link to git repository

You can now use the `!git-env` tag in an environment's .buzzy/links.yaml
file to explicitly refer to a git repository.  This lets you specify
the branch or commit to retrieve, in addition to the URL.
Per-environment per-recipe work directories

It's now easier to build packages for the same recipe, but from
different environments.  (For instance, by building a package manually
from a checked-out copy of its code, and also by having Buzzy build it
to satisfy a dependency while building something else.)  To support
this, we need separate working directories for each combination of
recipe and the environment that the recipe belongs to.  We calculate the
name of the working directory by taking a hash of the path to our local
copy of the environment.
Only install built packages when versions differ

Before installing a built package, we first check to see if we've
already built and installed this package, and if so, verify that the
installed version matches what we're about to build.  If the versions
match, then we don't need to do anything.  The version numbers that we
auto-compute from git tags include enough detail in them that any
different commit will trigger a rebuild.
Fix Arch prerelease tags

Our logic for converting from an Arch version back to a Buzzy version
was flawed on Arch versions such as 2.0.git123ef45.  This should
translate into the Buzzy version 2.0+git123ef45 — i.e., the whole tag
starting with "git" is a single postrelease tag.  However, our logic saw
that "ef" came right after a number, and thought that it started a new
prerelease tag, giving us 2.0+git123~ef45.  We now only look for release
tags after a release tag consisting only of numbers.
Always reinstall packages from dirty working trees

When building and installing a package from a git environment, we now
detect whether the git working tree is dirty.  If so, we always rebuild
and reinstall the package, even if there's already a version installed
with the same version number.  (The version number only indicates that
the tree is dirty; it doesn't keep track of which particular files have
been updated.  So we always have to assume that something might have
changed.)

You can also trigger this behavior manually by setting `always_rebuild`
to True in the recipe description.
Include dependencies in built packages

We now include actual dependency fields in the Arch and Debian packages
that we build.  I know, right?
Deduplicate common environments

With linked environments, it's possible for an environment to be
referenced more than once.  (For instance, env2 links to env1, while
env3 links to env1 and env2.  In this case, if env3 is the root
environment, we'll encounter env1 twice while iterating through the
links.)

When constructing environments directly from a URL string in the
links.yaml file, we were already deduplicating the results: if you
referred to the same environment twice (with the same URL string in both
cases), we'd only construct a single Environment instance.

However, when using a more complex YAML clause, along with a YAML tag,
the YAML parser would bypass that deduplication logic, and you'd end up
with two copies of the same environment.  This patch wraps some extra
logic around the YAML constructor for environments, adding the
deduplication back in.
Look for native Debian shared library packages

Before, we always assumed that a native package would have the same name
as the corresponding Buzzy package.  On Debian, shared libraries are
split into multiple packages, named libfooX and libfoo-dev, where foo is
the shared library name, and X is the latest soversion of the library.

Eventually, we'll want Buzzy to be smart enough to pull in the
libfoo-dev package as a build dependency, and the libfooX package as an
install dependency.  But for now, we're just going to use libfoo-dev.
This installs extra stuff that technically is only needed at build time,
but is the simplest solution for now.

Note that this also doesn't address when the "foo" portion of the
package names don't match the Buzzy package name.  We'll cross that
bridge later, too.
Merge branch 'feature/dependencies' into develop

* feature/dependencies:
  Look for native Debian shared library packages
  Deduplicate common environments
  Include dependencies in built packages
  Always reinstall packages from dirty working trees
  Fix Arch prerelease tags
  Only install built packages when versions differ
  Per-environment per-recipe work directories
  Explicit link to git repository
  Update remote environments before reading recipe
  Build and install dependencies in recipes
  Refactor built packages
  Refactor native packages
  Convert Arch and Debian versions to Buzzy versions