Plug leaks with allocated regular expressions

Sponsored-by: EMC / Isilon Storage Divison
Remove an unused variable
Merge branch 'master' into plug-leaks-with-regex-handling
Copy original_preg and fix a double-free

- Make a copy of original_preg so the regular expression object is valid
when the error is constructed [*].
- Fix a double-free with preg in kyua_tap_try_parse_plan(..) (I fixed this
before on a different branch..).

[*] Submitted-by: jmmv
Sponsored-by: EMC / Isilon Storage Division
Merge pull request #96 from yaneurabeya/plug-leaks-with-regex-handling

Plug leaks with regex handling
Revert "Fix typo with regex_match_to_long"

This reverts commit 41c566b4839c7227f4edfa816f4324dc356f8bc7.

The original function was correct: regex_match_to_long converts a
match to a long; it does not generate an error for "too long".
Add tests for TAP plans appearing at the end
Add init and fini methods to kyua_tap_summary_t

These are to allow the caller to manage the lifecycle of the object,
which we will need to hold dynamic strings within the result.
Implement support for TAP skip plans

TAP test programs can provide a "skip plan" to indicate that the whole
program is being skipped regardless of what its tests do.

Fixes #86.
Report passed tests that exit non-zero as broken

Fixes #92.
Handle lines that look like results but aren't

Lines containing "ok" and "not ok" only are supposed to be ignored.
To fix this, add some fancier parsing for the results so that we
only recognize ok/not ok lines if they also contain the corresponding
numerical identifier of the test.
Merge branch 'fix-tap'

The work in this branch is inspired by the contents of a pull request
previously submitted by Garrett Cooper but that was discarded.

Fixes #86, #90 and #92.
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).