Hi,

we've discovered an edge case some 32-bit architectures suffer from.
Specifically, archs using a 32-bit userland on a 64-bit kernel will
leak the 64-bit kernel from `uname -m` in the build environment.

Looking at DSA's modules/schroot/files/setup-dchroot, previously
these archs would _always_ use linux32:
     armel|armhf|i386|mips|mipsel|powerpc|s390|sparc

sbuild (with unshare) tries to support this out of the box, but it
has a more restricted view. It only applies linux32, if the host
userland is 64-bit and the target arch is 32-bit, for these specific
combinations:

     armel:arm64
     armhf:arm64
     i386:amd64
     mipsel:mips64el
     powerpc:ppc64
     s390:s390x
     sparc:sparc64

As can be seen on the Debian buildds, this works. However, when the
host userland is 32-bit, linux32 is not applied.

This is relatively important for users like reproduce.debian.net,
which picked an amd64 kernel, an i386 userland, and build for i386.
In this setup, linux32 is not applied, `uname -m` shows x86_64, and
packages using cmake see CMAKE_SYSTEM_PROCESSOR=x86_64, and then
packages like swi-prolog install into the wrong multi-arch triplet
path.

I think it would be a good idea to always apply linux32 on 32bit
archs, to avoid this leakage.

Thanks for considering,
Chris