Revamp alt compiler handling for clang 3.9.1 import.

Revamp alt compiler handling for clang 3.9.1 import.

Many users are still constantly asking weather llvm/clang compiler could be
added into a base as an alternative to current used ones (gcc50 and gcc47).
There are few issues in doing that:
 * It is very hard to keep both compiler flavors in harmony while one or the
   other is being updated. There were always two base compilers in base system
   in DragonFly and common practice still is to replace previous alternative
   compiler with an updated version, performing tests and then flip them up.
 * With clang introduction, this scheme would break badly due to both using
   slightly different c++ capabilities, flags support (WARNS mechanism), etc.
 * Different incompatible libraries libLLVM + libc++ vs libstdc++, also clang
   requiring a lot of effort to rewrite cmake logic into Makefiles for make(1).
 * SBU costs, gcc47 only has ~4min buildtime overhead at -j5 level(i7 laptop)
   while even clang38 tests has shown two-fold increase in buildworld time.
 * How DPorts infrastructure would handle both flavors? License roadmap?

So to make compromise it was chosen to provide a way for users and developers
to select the alternative compiler they like while keeping all groups happy,
ones continuing to enjoy the very fast world rebuilds and others having a way
to further develop and integrate clang into the infrastructure. Since DragonFly
is currently x86_64 only, we might as well experiment more with compilers.

This changeset adds some flexibility when it comes to handling base system
compilers. Even if it would be decided that clang does not fit very well in
DragonFly base system (due to complexities, updating/patching problems and
compilation times), we at least will have a very clean way for adding,
testing and finally making base default upcoming gcc70 and later. All of this
would be possible without disturbing both primary and alternative default
compilers, while developers and users will be testing both base and dports.
Also as a bonus we will be able to add compilers like pcc and scc that have
no native c++ frontend support too while reusing default compiler parts.
For now I am keeping this expansion undocumented and candidate for a revert.

While there mark few places for further work to reduce amount of ORDER: for
faster/better parallelism in btools/ctools bootstrapping stages.

Bootstrap is still fine from DragonFly 4.0.6-RELEASE.