reuse stage0 binutils and make, to not build them again in stage1

since the stage0 binutils are already linked against musl, there
is no good reason except of the "standalone, sysrooted toolchain"
feature to build them twice.
i feel the slight potential performance advantage that rebuilding
binutils with gcc 4 does not justify building it twice.

this also makes the buildscripts much cleaner.
i'll look how i can integrate the butch template into stage0, so
the binutils and make built there behave like a proper package
(in /opt/packagename, symlinked into /).
stage0 config: make $S point to $R/src by default

that way we have everything where it should be, and can treat
stuff like we do in stage1.
this way we have build dir in /src/build, and butch can see the
packages installed during stage0 in /src/pkg/installed.dat.

i don't know why it originally used two distinct paths, this was a
leftover from original sabotage by chneukirchen.
rework stage0 build scripts so that stage0 and stage1 can use the
same packages. build stage0 with the usual butch template.

to get it right, a new variable is "exported" from the butch
template: butch_root_dir.
it can be used to reference needed files (like musl-gcc) during
stage0 builds. the next step will be to merge stage0 and stage1
packages.

to get the butch template right, i dropped some support code
for the "stage U" idea, which was quite hacky. maybe i'll remove
it entirely or fix it to behave saner.
remove STAGEU and fixdestdir hacks
merge both binutils into one package.

to detect if we're using stage0 or stage1, a new variable has been
added to the config templates.
merge the patch recipes
merge make recipes
make it so gcc3 could even be built after chrooting

gcc3 and gcc42 (previously only used for arm stage0) are now reg-
ular packages.

a metapackage called pkg/stage0_gcc decides which one is used for
stage0 (build-stage will overwrite it inside the build dir).
merge butch recipes
merge busybox recipes

we build the full blown busybox now in stage0 using musl-gcc.
this saves us from building it twice.
remove config-cache package (replaced by $K reference in template)

the butch build template references the config.cache in $K directly
now.
remove "relocate_toolchain"

this served the purpose to build a standalone toolchain in
/opt/toolchain. musl, gcc4, and binutils were built in there
with sysroot features, so that you could rip out the entire dir
and use it in a free-standing fashion on any compatible arch running
linux.
relocate_toolchain was the finalizer script that linked all files
from there into /.

as noble and useful as this was, it lead to bunch of ugly hacks
in the affected buildscripts. additionally the build template
had to be circumvented by quitting prematurely.

possibly the same result of a standalone toolchain can now be
achieved by simply copying the contents of
/opt/binutils
/opt/gcc4
/opt/musl
into a common root directory.
if not, it's now quite simple to use musl-cross to build something
very similar.
fix binutils so they can be built statically even with libc.so
present.

libtool is trying to deny us to build it statically.

there are 3 flags that can potentially circumvent it:
-Wl,-static
--static (this one seems to work by pure luck)
-static-libgcc (this breaks the build because of a missing
dl_iterate_phdr function which libgcc wants to use)