[build2] Standard pre-installed build system modules

[Boris Kolpackov]

This is primarily a heads-up to the folks making distribution packages
of build2.

While we can build and load build system modules on the fly, this will
be inconvenient and inefficient for widely-used modules. As a result,
with the upcoming release (0.14.0) we are introducing a notion of
"standard pre-installed build system modules" that the user can
assume are available out of the box in a regular build2 toolchain
installation. In particular, the "official" install scripts will
build and install such modules unless explicitly requested not to.

The first such build system module is libbuild2-kconfig and it is
already part of the staged toolchain. If you look inside the
build2-toolchain amalgamation, you will see that there is now the
libbuild2-kconfig/ top-level directory. As a general rule, all
(and only) the standard pre-installed modules will be included
into this amalgamation as libbuild2-<name>/ top-level directories
with their tests available in tests/libbuild2-<name>-tests/. Here
is the structure of the relevant directories:

build2-toolchain-X.Y.Z/
├── libbuild2-kconfig/
└── tests/
    └── libbuild2-kconfig-tests/

In other words, this structure is regular and you should be able to
handle all modules in a generic way if you wish. Before the final
0.14.0 release we are planning to add two more such modules:
libbuild2-bash (factored from the build2 itself) and libbuild2-rust.

Now on distribution packaging: the key point that I would like
to stress is that such modules should be installed as part of
the build2 build system unless explicitly requested by the user
not to. Failed that, the "available out of the box" part I
mentioned above does not hold. In a sense, the only reasons
these modules are not made part of the libbuild2 library itself
are:

1. So that projects that don't use certain modules won't have
   to load them.

2. So that modules can be developed independently.

Based on this, I see two plausible strategies for distribution
packaging: bundle the modules with the build system itself or
make them a separate package or packages with the build system
reverse-depending on this package in such a way that by default
installing the build system triggers the installation of the
modules (e.g., "recommends" in Debian).

Note also that because of #2, modules are versioned independently
of build2. However, each release of build2 will fix the set and
versions of the standard build system modules with only patch
version variations allowed (we may relax this once we are out of
the alpha phase and have stable build system interfaces).

Let me know if you have any questions or concerns.