Major reworking of configuration mechanism.

The "flx" program now uses the file config file toolchain.fpc
field toolchain to select a toolchain. Toolchains provide access
to C/C++ compilers and linkers, and details of filesystem
conventions on pathnames and extensions.

As of this version, only 4 toolchains are built-in:
toolchain_clang_osx, toolchain_clang_linux, toolchain_gcc_osx
and toolchain_gcc_linux. Windows toolchain_msvc_win32 needs to be
created for Windows support, but I cannot do that lacking a test
platform.

In future version of "flx", any other toolchain could be nominated.
In that case, flx will dlopen the toolchain plugin. The builtin
toolchains are used to make the bootstrapping process simpler:
the Python script has to build flx_pkgconfig and flx, but not
any plugins. Similarly, flx_build_rtl tool can rebuild Felix
system with flx, and use that flx to build any plugins,
so the use of any non-builtin plugin will require a double
bootstrap. This needs to be fixed but it will do at the moment.
It means you can make a new toolchain and switch to using it,
but you have to use a builtin one to make it first (directly
or indirectly).

Flx has a new switch --target=target-subdir. The default is
'host'. This is a sub-directory of the install directory
(which can be changed by --test=directory option) which
identifies the configuration for a processing run.
I do not like that this must be a subdirectory.
The master directory must contain "share" subdirectory
for read-only platform independent sources as well
as a "host" target.

In the Makefile I am experimenting with making a new
target on my Mac, namely, gccosx. This is a target that
uses toolchain_gcc_osx as the compiler toolchain, instead
of the default, which is clang. So I should be able to
run programs using either clang or gcc at the flick of
a switch, and thus check stuff compiles under both,
as well as comparing performance.

The target/lib/plat/config.flx record which is originally
generated by lpsrc/flx_maker.pak interscript script no
longer contains any toolchain information, nor the
version. It is left containing a legacy LINK_STRINGS
function which will be removed, and a set of PLAT_XXX
flags telling which OS is running. I hope to remove all
of that and put it in the pkgconfig database instead.

In the real world the dynamic toolchain selection is vital
for enterprise deployment, as well as on nasty platforms
like Cygwin which have access to multiple Windows compiler
toolchains (32 and 64 bit MSVC) as well as a Cygwin
based gcc (all of which make windows executables and dlls
but with different compiler and linker technology).