Use tmpfs instead of md in FreeBSD

This prevents leaking md devices automatically spawned by mdmfs, which we
do not explicitly clean.  It's just easier to rely on tmpfs that attempt
to add cleanup routines.

Fixes #105.
Run tests as root with unprivileged_user set

Add a new configuration in the Travis CI runs to ensure that running our
own tests as root works properly when unprivileged_user is set.
Properly drop group privileges

As a side-effect, this fixes testers/run_test:fork_wait__unprivileged_group
which was properly capturing this failure.

Fixes #109.
Fix opening of log files with unprivileged_user

When running with unprivileged_user set, opening log files using the
/dev/stdout and /dev/stderr names fails because these special files
are not owned by the user the privileges were dropped to.

To resolve this, apply the same indirection we have in the CLI when
opening output files for reports: capture the /dev/stdout and
/dev/stderr special names and redirect them to the already-open
std::cout and std::cerr streams.

Fixes a bunch of test failures when running the Kyua test suite as
root with unprivileged_user is set.
Fix test broken by the TMPDIR change

The change in 6ea3e39a100ca3ca2f8c36ea30e6c8e60a50ef70 to make TMPDIR
point to the work directory of the test case broke the
run_test_case__atf__required_user__atf__unprivileged__atf__drop test
in engine/test_case_test.

The breakage came because the unprivileged test case spawned by this
test case had its work directory within the work directory of the
container test case, which in turn had its work directory set to
root with 0700 permissions.  This prevented the unprivileged test
case from creating its results file as absolute paths could not be
resolved.

Fix this by weakening the permissions of the first work directory.
Merge branch 'unprivileged-user-fixes'

Fix privilege dropping functionality and a bunch of broken tests when
running the Kyua test suite as root with unprivileged_user properly
set.
Clarify what the 'about' command prints

Change the synopsis of the 'about' command to mention that it shows details
on authors, license, and version.
Print a header with the program version in "help"

Change "help" to output a heading line with the version number of Kyua
in it.
Merge branch 'issue-110'

Fixes #110.
Simplify dependencies in flags

Rely on the transitive dependencies defined by our <MODULE>_{CFLAGS,LIBS}
variables when defining the flags for all test programs.  This is simpler
to manage.
Introduce the model module (and move test_results)

The new 'model' top-level module is intended to contain the data model
of Kyua: that is, the in-memory representation of the concepts related
to a test suite and its results.

The classes in this module are intended to be well-defined, simple data
containers with a direct mapping to their on-disk representation in the
store.  Stateful instantiation of the classes (as in: lazily loading the
test cases of an ATF-based test program) should happen in the engine
module.

To get the module started, this change moves the test_result class out
of engine and puts it in store.  The chunk of this module involved in
parsing the output of the testers (something that is not part of the
data model) remains in the engine.

As a side-effect, transitioning all the data types to the model will
allow us to break the interdependency between the store and the engine
(which is just a minor benefit).
Move metadata and metadata_builder to the model

These two classes are pure data types that belong in the model.  Split out
the actual checking of requirements from the metadata module into its own
module that remains in the engine.
Move context to the model

Split out the construction of the context from the current environment out
of the class.  This is an operation to be performed by the engine.
Move the drivers to a top-level directory

The engine/drivers directory made sense when the only top-level directories
were cli, engine and utils.  Now that we have other sibling directories to
represent other parts of the system (i.e. store and model), keeping the
drivers inside engine is suboptimal: the drivers exist to orchestrate all
the other modules, so they deserve being top-level.
Move report_junit to the drivers module

This seems a bit odd, but the fact that report_junit requires the
scan_results driver means that, dependency-wise, this also belongs in
the drivers.  Conceptually, we'd also argue that generating a report
is something that relies on various pieces of the system and thus is
a driver.

We'll see how things turn out once we refactor the engine module even
futher to only contain the execution of tests.
Move test_case to the model

Split out the test_case type definition out of the engine and put it into
the model.  The old test_case module remains in place within the engine
as it still includes the logic to run the test case, and this will be
addressed later.
Add a new utils/format/containers module

This module contains utility functions to provide output operators for
various standard containers.  This is to avoid having to define custom
operators for typedefs.
Move test_program to the model (last concept)

Split out the test_program type definition out of the engine and put it into
the model.  The old test_program module remains in place within the engine
as it still includes the logic to load the list of test cases.  This is
incredibly ugly due to the way this happened lazily in the past, but will be
cleaned up later.

This change is also the last move of a high-level concept from the engine to
the store.  As a result, this finally breaks the cyclic dependency between
the engine and the store.  The dependency chain is now a clean and simple
"engine -> store -> model" sequence.
Move test case execution code to a runner module

Merge the remains of the test_program and test_case modules of the engine
into a single "runner" module that contains no data definitions.  Do this
to prevent having modules with the same names in different component (which
is annoying to manage) and also to make it easier to transition to the new
execution code that is coming.