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.