currently the board sysroot setup process runs install_toolchain which basically does:
- grab glibc tarball from the cross-xxx/glibc toolchain
- run `tar xf` on it into the /build/$BOARD/ sysroot
- drop the /usr/$CTARGET/ prefix (due to the cross-compiler package)
- prune some files along the way

doing `tar xf` on the glibc tarball into the sysroot means we lose complete track of the files.  normally this isn't a problem because glibc doesn't remove files, just add ones, but it causes problems when glibc actually removes files.

we saw such a scenario when upgrading from glibc 2.23 to glibc 2.27: xlocale.h (a commonly checked header) and rpc/ headers were dropped.  when packages tried to use that file from glibc-2.23 against an otherwise glibc-2.27 install, it lead to weird build failures.

we deployed an upgrade hook to manually clean things up:
  https://chromium-review.googlesource.com/1335861

but ideally we should be able to upgrade this like any other package.  so instead of manually unpacking a tarball, we could rewrite it to be another portage binpkg.  portage-utils provides some low level tools to help accomplish this.

which means the process would be:
- grab glibc tarball from the cross-xxx/glibc toolchain
- use `qtbz2` to split the tbz2 into a tar.bz2 and an xpak file
- unpack the tar.bz2 file and delete/move things around
- unpack the xpak file and update the various metadata files that make sense
  - CONTENTS def needs rewriting, but maybe a few other fields might too
- repack the tar.bz2 & xpak files
- use `qtbz2` to repack the tbz2 binpkg
- clean up everything except the tbz2
- use portage to install the tbz2

this would give us normal file tracking so that when we do the upgrade next time, portage would automatically unmerge old files.