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.
Merge branch 'model'

This merge brings a major reorganization of the source tree in prepartion
for a rewrite of the execution engine to support parallel execution of
test programs.  These changes should be a no-op in functionality.

More in detail:

- The data model of Kyua is now self-contained in the new "model"
  component.  This component provides pure data types for all of the
  classes involved in representing a test suite.

- All of the run-time logic to run test programs remains in the engine.

- Thanks to the previous two points, we finally break the cyclic
  dependency between the engine and the store.  As of now, the chain
  is linear: the engine depends on the store and the model, and the store
  depends on the model alone.

- The drivers have been moved to a top-level directory instead of being
  a subdirectory of the engine.  This is mostly just to flatten the source
  tree and make it more manageable, but also helps in giving the idea that
  the drivers exist to coordinate various parts of the codebase and now
  only those in the engine.
Add kyua_env_{check,set}_configuration

These new functions are to be used by the plain and TAP testers to pass
user-provided configuration variables through the environment.

I am abusing the env module to hold these functions as they are generic
enough to not live in the testers' code themselves, and I don't feel like
adding one more module for them.
Pass configuration variables to plain tests

Change the plain tester to pass any user-provided configuration variable
to the test program via the environment.  All the environment variables
set in this manner are prefixed with TEST_ENV_.
Pass configuration variables to TAP tests

Change the TAP tester to pass any user-provided configuration variable
to the test program via the environment.  All the environment variables
set in this manner are prefixed with TEST_ENV_.
Merge branch 'issue-84'

Pass test-suite configuration variables to plain and TAP test programs
via the environment.  The name of the environment variables set this
way is prefixed by TEST_ENV_, so a configuration variable of the form
'test_suites.some_name.allow_unsafe_ops=yes' in kyua.conf becomes
'TEST_ENV_allow_unsafe_ops=YES' in the environment.

Fixes #84.