3. */build.sh installs software into "inst" (run-time + compile-time)
	4. */build.sh installs run-time software into "out", this will be
	   included in the Tclkit as if it were the root directory of the
	   Tclkit (combined with other "out" directories)
	5. kitsh/build.sh compiles a "main" function and links all the built
	   libraries together into an executable
	6. kitsh/build.sh combines all the "out" directories into one
	7. kitsh/build.sh creates a Metakit or Zip database from the combined
	   directories and appends that to the compiled executable using:
		a. A Tclkit found in the environment variable "TCLKIT" (tclkit
		   if unset) if it is functional; or
		b. The built kit itself (does not work for cross-compiling)

Details:
	The general mechanism that enables a Tclkit to operate is a small Tcl

the individual projects together into a single executable.  Its build script
does not create an "inst" or an "out" directory because it is not a library.
Instead, it collects all the other project's "out" directories into a single
directory (starpack.vfs), as well a static file (boot.tcl).  It then compiles
the source code, and then installs the Metakit database containing the VFS
onto the resulting executable.

If the "mk4tcl" project fails to build (or is not requested to be built),
the rest of the project will be built using zip files instead of Metakit
databases.

To create the Metakit database (if needed), one of two Tclkits is used (tried
in this order):
	1. The Tclkit specified by the TCLKIT environment variable (or
	   "tclkit" if that variable is not set) if it is functional; or
	2. The built Tclkit itself

The second method will not work if the built Tclkit is not executable on the
current platform (i.e., in the case of cross-compilation) and so it may be
necessary to bootstrap a runnable Tclkit first.