Version strings

Since we're going to support a bunch of different packaging systems,
each of which has a slightly different versioning setup, we're going to
have a bit of a mess on our hands.

This patch adds a class for representing version numbers.  I'm trying to
make it relatively easy to parse version numbers from a bunch of
different schemes, and still have them be interchangeable.  We'll see if
that works.

In this setup, a version is a list of parts.  Each part is either a
release tag, a pre-release tag, or a post-release tag.  (Each version
also ends with a special "final" tag, which is only there to make the
comparison algorithm work.)  This is very much like how setuptools
parses version strings, but we're not going to require setuptool's
particular encoding of versions as strings.

With this representation, we can compare versions lexicographically,
where individual parts are ordered as follows:

  pre < final < post < release

This works perfectly, as long as we make sure to not include any "0"
release parts in the comparison, unless they're followed by a non-"0"
release tag.  (This is to ensure that 2.4+dev compares greater than
2.4.0, but less than 2.4.1, for instance.)

We do have a string encoding for these version numbers, where each part
is explicitly prefixed by a ".", "~", or "+" to indicate whether it's a
release, pre-release, or post-release tag.  However, most of the rest of
the code-base will deal with the version parts directly, so we can
construct OS-specific version strings more easily.  I hope.
Package dependencies

A package dependency is the request to perform some operation on some
package.  The goal of Buzzy will be to perform actions that satisfy
these dependencies.  The most common operation is `install`, which
causes the package to be installed onto the local system in some way
that makes it usable by the user, or by other packages.  Other
operations might include `build` or `test`, which would be useful during
development.
Functions for running subprocess commands

Quite a lot of the package builders will need to run external commands
to do the bulk of their work.  This patch adds some helper functions for
that.  There are three variants: `get`, `if`, and normal.  The `get`
variant returns the stdout of the command.  The `if` variant returns
True if the command exits successfully, False otherwise.  And the normal
variant just runs the program, hiding any output unless the user
requests verbosity or there's an error.  There are also `sudo` versions
of each that will run the command as root.

The functions can be mocked out for test cases.  This patch shifts the
existing configuration variable testing code into a new
unittest.TestCase subclass, and adds additional default setup and
teardown logic that installs mocked versions of the subprocess runner
functions.  You must provide a mock for each of the commands that will
be run by the test case.  The mock can either be an explicit exit code,
stdout, and stderr, which will be used directly to construct the
functions' return values; or it can be an instruction to allow the
command to passthrough to the "real" function implementations, allowing
the commands to actually be run.
Mock support for Actions

The existing test case for Action objects has custom perform methods
that wouldn't actually do anything; instead, they'd append to a list of
"performed operations" so that we could test the order that things were
performed.  We want to support these kinds of tests with "real" actions,
too — i.e., those that would be used to build and install packages.  So
I need to move the mocking support into the code that performs actions.
Arch Linux version strings

This patch adds a function that converts Buzzy versions into equivalent
Arch Linux version strings.  (I.e., an Arch version string that looks as
identical as possible, but compares the same way.)  Arch treats an
alphabetic suffix as a prerelease if there's no intervening `.`, and as
a postrelease if there is one.  This gives the following Buzzy → Arch
conversions:

   2.0           2.0
   2.0~alpha1    2.0alpha1
   2.0~1         2.0pre1
   2.0+hotfix1   2.0.hotfix1
   2.0+1         2.0.post1
Environments and packages

In Buzzy, a package is anything that can satisfy a package dependency.
That's really the only thing in common across all of the different ways
of building and/or installing a “package”.  An environment is a
collection of packages.  Packages and environment aren't defined in any
one way.  For instance, the first environment that we've created knows
how to satisfy Buzzy package dependencies by installing system packages
on an Arch Linux system.  For this environment, there are no explicit
(Buzzy) package descriptions; instead, we know how to translate a Buzzy
package name into the corresponding Arch package name, and then use
Arch's pre-existing package database to see if a dependency refers to an
Arch system package.
Merge branch 'feature/packages' into develop

* feature/packages:
  Environments and packages
  Arch Linux version strings
  Mock support for Actions
  Functions for running subprocess commands
  Package dependencies
  Version strings