add libstdc++ package

programs that are cross-compiled will end up with a hardcoded
reference to the cross-compiler's libstdc++ library,
and that breaks usage of --with-sysroot, which has the result
of adding the sysroot path to all library paths returned by libtool.
therefore we must explicitly add libstdc++ to the deps, to ensure
that the native gcc/libstdc++.so is built, which does not have this
problem.
pango,libtiff: add libstdc++ as dep

this ensures that even in crosscompile scenarios the native host toolchain
is built and libtool files for the cross compiler's libstc++ don't get
in our way.
use --with-sysroot instead of "big hammer" to make libtool happy

background: I experienced libtool-related cross-compiling breakage
due to .la files returning paths pointing to the target rootfs instead
of picking paths from our -L flags, which would in a normal linkage scenario
pick the libraries installed in our x-compile "staging" directory.

the "big hammer", in our case simply rm'ing the offending libtool files,
had a nasty side-effect: library dependencies were not added automatically
anymore so we had to specify by them by *hand* for every single package.
this was a bad idea and would become a maintenance nightmare quickly.
add libtool.cross.gen

some packages ship a libtool (generated from ltmain.sh) which was generated
with an ancient libtoolize version, and are not compatible with cross-compiling
(they lack support for lt_sysroot).
some of these packages, most notably SDL 1.2.15 will likely not see any more
releases (end of life), so we can't hope that upstream gets it fixed.

adding such a huge script is quite contrary to sabotage's goals, however all
alternatives are considered worse.
those would be (among others)
- hack in buildscript to re-use libtool of some other package that uses a
  known-good libtool version (this would work as long as build dirs were not
  cleaned up recently, and no mix of native and x-compiled build dirs exist),
- make the offending packages depend on the entire auto* stack
  and regenerate the files (configure/libtool)
     $ libtoolize --automake
     $ aclocal -I ${SYSROOT}/usr/share/aclocal \
        [-I <dir_containing_your_project-specific_m4_macros>]
     $ autoconf
     $ autoheader
     $ automake -a
  however this depends on a ton a highly fragile/redundant/overdesigned stuff,
  which may even depend on gnu gettext (autopoint) and the existence of some
  3rd party m4 scripts in /share/aclocal...
- force the x-compile user to install a local "cross-libtool"
  ( http://metastatic.org/text/libtool.html ) which would be passed via LIBTOOL
  env var.
- adopt mlibtool and get it fixed for all usage cases of any package in sabotage
  so a fallback to the package's libtool never happens.

the third option seems the best of the bunch, however it puts yet another
complexity on the user's shoulders.
so we bite the bullet and add 260KB bloat to the repo...
fix x-compile for a couple packages missing a sufficient libtool version

we need to use the new libtool.cross.gen to generate a proper libtool.
postfix: add missing main tag
add butch-checktarballs
config.stage1: revise comment about butch template.
introduce butch download template

this allows to set user-defined $wgetflags
(like retry, no certificate check, etc).
it also could be used to test for curl and use that in case it's available.
the template returns 44 in case a 404 is encountered.
this could be used to detect packages that have no single valid mirror url,
in which case retrying over and over to download could be caught in butch.

this first revision is deliberately kept simple.
as a first improvement, tarballs are downloaded to a temporary location first.
that way interrupted butch sessions (CTRL-C) will resume the tarball download
rather than erroring out due to size/hash mismatch.
use hostdeps for cmake
libao: bump to latest
fix xorg and lxde packages for x-compile