`containertool` could choose a distroless base image for static binaries by default

`containertool` reads the CPU architecture from the ELF header of the target executable in order to find a compatible base image.

It could also check whether the executable is statically- or dynamically-linked and choose a more suitable base image:
* If the executable is dynamically linked, use an image which provides the standard Linux dynamic libraries and the Swift runtime
* If the executable is dynamically linked, but with the Swift runtime linked in (`--static-swift-stdlib`), use a generic Linux base image without a Swift runtime
* If the executable is statically linked, use a distroless base image which only provides a bare minimum of resources, such as a root certificate bundle.

This would require `containertool` to be able to parse the program header (linking type), and possibly section header (linked libraries), whereas currently it only reads part of the overall ELF header.

Start by locating containertool's existing ELF-header parsing and base-image selection, then inspect how program headers and, if needed, section headers expose static or dynamic linking. Done means selecting suitable Swift-runtime, generic Linux, or distroless images for the three linking cases while preserving architecture compatibility; no test file is named in the issue.

Written by the indexing model from the issue text.