Document the base module in manpages

Add manual pages for the functions provided by the base module, which at
the moment is only shtk_import(3).

To support this change, and to allow the discoverability of all function-
specific pages, introduce the new shtk(3) page, mention the former from
shtk(1), and write down some guidelines in the man/README file on how
these pages should be structured..
Document the bool module in manpages

This adds the manual pages: shtk_bool(3) and shtk_bool_check(3).
Document the cleanup module in manpages

This adds the manual pages: shtk_cleanup(3) and shtk_cleanup_register(3).
Document the cli module in manpages

This adds the manual pages: shtk_cli(3), shtk_cli_dirname(3),
shtk_cli_error(3), shtk_cli_info(3), shtk_cli_progname(3),
shtk_cli_usage_error(3) and shtk_cli_warning(3).
Document the config module in manpages

This adds the manual pages: shtk_config(3), shtk_config_get(3),
shtk_config_get_bool(3), shtk_config_get_default(3), shtk_config_has(3),
shtk_config_include(3), shtk_config_init(3), shtk_config_load(3),
shtk_config_override(3), shtk_config_run_hook(3), shtk_config_set(3) and
shtk_config_unset(3).
Document the cvs module in manpages

This adds the manual pages: shtk_cvs(3), shtk_cvs_checkout(3),
shtk_cvs_fetch(3) and shtk_cvs_update(3).
Document the list module in manpages

This adds the manual pages: shtk_list(3), shtk_list_contains(3) and
shtk_list_filter(3).
Document the process module in manpages

This adds the manual pages: shtk_process(3) and shtk_process_run(3).
Document the version module in manpages

This adds the manual pages: shtk_version(3), shtk_version_at_least(3),
shtk_version_at_most(3) and shtk_version_is(3).
Remove last remaining docstring-like tags

With the conversion of all documentation to manual pages, we have removed
all Doxygen, docstring-like comments from all modules.  Remove the last
remaining instance of this from bootstrap.subr.
Move shtk.1.in into man

For consistency with the rest of the manual pages, move shtk.1.in
into the new 'man' subdirectory.
Merge branch 'manpages'

This brings in manual pages for all public API functions, with their
starting point being shtk(3).

The docstrings of all public API functions have been removed in favor
of the manual pages.  Only docstrings for private functions remain in
the code.
Introduce the unittest module

This new 'unittest' module is intended to support the creation of test
programs using an interface similar to that of JUnit-like frameworks.

At the moment, all this module allows is defining simple test cases
without support for fixtures and has no assert-style functions other
than the explicit "fail" call.  These extra features will all be added
separately.
Add support for skip tests to unittest
Add support for test fixtures

Fixtures are sets of related test cases that share some common setup and
teardown code.

Because the shell does not have scoping for nested functions, and because
we lack the equivalent of classes, we play some tricks to emulate the
common syntax found in JUnit-like libraries.
Treat returning from setup/test/teardown as a pass

If setup/test/teardown evaluated a command as false as their very last
statement, the test case would be misteriously marked as failed.  This
is unexpected and surprising (especially because we do not "set -e")
and thus should not happen.

Change the code to discard the value of the last evaluated statement
so that, if the execution falls through the end of setup, test and
teardown methods, the test case is considered a success.

These routines can still "exit 1" (through "fail") to mark a failure.
Add test for imports with subdirectory components

We will be using this feature in subsequent commits so we must ensure it
works.
Add delayed failures to unittest

Extend the unittest library with a delayed_fail method that permits a
test case to record a failure while continuing execution.  This will be
useful to implement expect-style failures.
Add the register_check method

This internal function automatically generates an assert/expect pair of
functions for a corresponding check function (of which we have none yet).

We will be using this to easily generate boilerplate code around
low-level check functions and to ensure that all assert/expect pairs
behave the same.
Add expected failures

This feature currently does not support delayed failures due to the
complexity involved in implementing them and the little value in
doing so.