Split transaction into {read,write}_transaction

The high-level workflows in Kyua either write to the database or read
from it, but never do the same at once.  Start clarifying this by splitting
the transaction class into a read-only version and a write-only version.
Move store migration code to a new module

The migration-related code is not tied to the backend class at all given
that it operates underneath it.  Separate into a different module.
Split backend into {read,write}_backend

This is similar to the split of the transaction class into read-only and
write-only versions.  The high-level workflows of Kyua do not do both at
the same time, so splitting the backing classes will allow for some
simplifications later.
Move get_home to utils/env

This was originally added to the cli helper code but it makes sense for
such a function to exist in the environment-management module.
Add a new releaser module

This module contains a single releaser class that provides a RAII
pattern to destroy pretty much any kind of dyamically-allocated
object.

This was previously implemented within the testers module as an
object_releaser local class, which this change is just exposing
for reuse.
Add the store::layout module

This module contains the logic to compute paths to independent,
per-test-suite, per-action database files and to find the latest
of them at any given time.

This will be used instead of a single database file for all actions.
Switch to per-action database files

This massive change gets rid of the cross-action store.db file that records
the details of all actions in a single location and switches to creating
a separate file for every executed action.

In particular:

- Every 'kyua test' run will now create a new file under ~/.kyua/actions/
  (unless specified otherwise via the --store flag) to hold the results of
  such run.  The name of the file is derived from the current directory and
  a timestamp.

- 'kyua report*' commands automatically determine the latest file
  corresponding to the test suite in the current directory.

- Commands that would previously create an empty database if it didn't
  exist (db-exec notably) now fail if the database doesn't exist.

- The --action flag is gone.

Note that this is not yet complete.
Bump the schema version to 3

This change just copies version 2 of the schema to a new version 3 to pave
the way for the removal of the actions.

Because we have not yet defined how version 3 will look like, the migration
path from 2 to 3 is not implemented and thus some tests are now broken (as
expected failures).
Remove the action class and actions from the store

First pass at getting rid of actions from the kyua internals.  This
involves removing the engine::action class, renaming the scan_action
driver to scan_results, removing the get_action_results method to
get_action and removing the actions table from the store schema.

There are still remains of the action_ids left in many interfaces
that need to be removed and there are various broken tests as well.
Get rid of the context_id

With the removal of the concept of actions, a database can now only
contain a single context.  For this reason, we do not need to keep
a "context_id" any longer, so remove it.
Fix integration tests for v3 schema
Add an utils::text::replace_all function

This is to just apply a literal string replacement on an input string.
Will be used later in the implementation of database migrations.
Add a new utils::fs::copy function

This is just a generalization of the file copying functionality that
existed in the store/migrate module so that we can easily reuse it.
Add v2 to v3 schema migration

This change modifies "db-migrate" to support splitting an existing store.db
file into the corresponding per-action files that are associated with the v3
schema.

This is horribly complex and somewhat ugly from the point of view of the
user.  However, I'm going to assume two things to excuse making this any
nicer:

- First, not that many people out there care about the historical contents
  of their Kyua database.  The way NetBSD and FreeBSD test suites run,
  they are already generating a single file per run and not taking advantage
  of any of the historical support in the store.

- Second, we should kill all this transitional support in the next release.
  Supporting schema upgrades within a database is worthwhile and relatively
  simple to implement, but maintaining the support to transition from
  monolithic databases to per-run databases is what makes the whole
  implementation super-tricky.
Remove useless cli/cmd_db_migrate_test

Test programs with a single "todo" test case are useless.  I removed a
bunch of them a while ago and it seems this one was missed.
Introduce the "tests results file" terminology

Start calling the files that store the results of a test suite execution
"tests results files".  No need to use a fancier name to represent this
concept.
Rename ~/.kyua/actions/ to ~/.kyua/results/

Actions are a name of the past.  We now have results files, so make
sure the directory that holds them reflects the correct name.
Rename --store to --results-file

With the removal of the actions, we do not have a unified store any
longer.  Instead, we have independent results files and therefore the
command-line flag to configure their location should reflect this new
nomenclature.  Make it so.
Homogenize naming scheme to "results file"

One more pass at replacing occurrences of "action files" and the
"store database" to refer to the files containing the results of
test suite executions as "results files".
Add the fs::is_directory function