Add fix for building Swift SDKs from Debian Trixie containers

[xtremekforever]

I am building my own debian:trixie containers with the Ubuntu 24.04 Swift toolchain included and feeding that into the swift-sdk-generator. However, it seems that starting with Debian Trixie, a new /usr/lib/linux directory is included that is symlinked from multiarch /usr/include headers in the sysroot. For example:

$ ls 6.2.1-RELEASE_debian_trixie_armv7/armv7-unknown-linux-gnueabihf/debian-trixie.sdk/usr/lib -ls
total 40
20 drwxr-xr-x 16 xtremek xtremek 20480 Dec  5 19:27 arm-linux-gnueabihf/
 4 drwxr-xr-x  4 xtremek xtremek  4096 Dec  5 19:26 clang/
 4 drwxr-xr-x  3 xtremek xtremek  4096 Dec  5 19:26 gcc/
 0 lrwxrwxrwx  1 xtremek xtremek    39 Aug  5 17:34 ld-linux-armhf.so.3 -> arm-linux-gnueabihf/ld-linux-armhf.so.3
 4 drwxr-xr-x  3 xtremek xtremek  4096 Dec  5 19:26 linux/
 4 drwxr-xr-x 13 xtremek xtremek  4096 Nov  5 13:14 swift/
 4 drwxr-xr-x 11 xtremek xtremek  4096 Nov  5 13:14 swift_static/
$ ls 6.2.1-RELEASE_debian_trixie_armv7/armv7-unknown-linux-gnueabihf/debian-trixie.sdk/usr/include/arm-linux-gnueabihf/asm -la
total 8
drwxr-xr-x 2 xtremek xtremek 4096 Dec  5 19:26 ./
drwxr-xr-x 9 xtremek xtremek 4096 Dec  5 19:26 ../
lrwxrwxrwx 1 xtremek xtremek   40 Nov  5 14:56 auxvec.h -> ../../../lib/linux/uapi/arm/asm/auxvec.h
lrwxrwxrwx 1 xtremek xtremek   45 Nov  5 14:56 bitsperlong.h -> ../../../lib/linux/uapi/arm/asm/bitsperlong.h
lrwxrwxrwx 1 xtremek xtremek   48 Nov  5 14:56 bpf_perf_event.h -> ../../../lib/linux/uapi/arm/asm/bpf_perf_event.h
lrwxrwxrwx 1 xtremek xtremek   43 Nov  5 14:56 byteorder.h -> ../../../lib/linux/uapi/arm/asm/byteorder.h
lrwxrwxrwx 1 xtremek xtremek   39 Nov  5 14:56 errno.h -> ../../../lib/linux/uapi/arm/asm/errno.h
lrwxrwxrwx 1 xtremek xtremek   39 Nov  5 14:56 fcntl.h -> ../../../lib/linux/uapi/arm/asm/fcntl.h
...

This PR simply copies the /usr/lib/linux directory from the container if it exists. When building a Swift SDK without a container for Debian Trixie, this directory is included in the *.deb packages and so works correctly.

Also updated the README.md file to show that Debian 13 is supported by the generator.

[MaxDesiatov]

We don't have a way to catch this on CI, do we?

[xtremekforever]

We don't have a way to catch this on CI, do we?

Not really, but I wonder if some unit test could be added to test folders copied from a "container"...we could have a simple matrix of folders that are expected for each distro we support, then ensure they are copied. What do you think?

[xtremekforever]

Thinking of another idea- we could test that all symlinks point to valid paths when we copy the files from the container and then throw an error if a symlink points to "nothing". Then add some unit tests that simply try a matrix of container copies and verify that each one succeeds.