FR: some library packages rely on postint for proper dynamic resolution

Title is generic as I think other libs may do this too?

The specific example I'm dealing with today are packages `libblas3` and `liblapack3` that install their shared libraries into a subdirectory of the dynamic library path (e.x. `/usr/lib/x86_64-linux-gnu/blas/libblas.so.3`), then in post install run `update-alternatives` to make the symlinks in the library directory.

Postint:
```shell
% cat libblas3.postinst.in
#!/bin/sh

set -e

update-alternatives --install /usr/lib/@DEB_HOST_MULTIARCH@/libblas.so.3 \
libblas.so.3-@DEB_HOST_MULTIARCH@ /usr/lib/@DEB_HOST_MULTIARCH@/blas/libblas.so.3 10

#DEBHELPER#

exit 0
```

The binaries that try to load them fail. My testcase is installing `gdal-bin` and running `ogr2ogr --version`, which will cry:
```shell
root@d876f2ae9478:~# ogr2ogr --version
ogr2ogr: error while loading shared libraries: libblas.so.3: cannot open shared object file: No such file or directory
```

I'm currently hacking around it with symlinks:
```starlark
# This is to hack around the fact that liblas3 and liblapack3 run a postinst to
# `update-alternates` and install their libraries in /usr/lib/$(uname -m)-linux-gnu/
#
# We don't run the postist, so just symlink the libraries to where they need to be
genrule(
name = "libblas.symlinks_mtree",
outs = ["libblas.symlinks.mtree"],
# double $$ to pass through the bazel make rule expansion
cmd = """
for lib in libblas.so.3 liblapack.so.3; do
DEB_HOST_MULTIARCH="$$(uname -m)-linux-gnu";
LIBNAME="$${lib%%.so.*}"; LIBNAME="$${LIBNAME#lib}";
echo "usr/lib/$$DEB_HOST_MULTIARCH/$$lib uid=0 gid=0 time=0 type=link link=/usr/lib/$$DEB_HOST_MULTIARCH/$$LIBNAME/$$lib"
done > $@
""",
)

tar(
name = "libblas.symlinks",
mtree = ":libblas.symlinks_mtree",
)
```

Filing the issue as an errata I guess, as I have a workaround in hand. Does this seem like a "best practice" for something like this? I don't really expect `rules_distroless` to handle this out of the box unless it was a common library pattern (and it doesn't seem to be).

Start with the libblas3.postinst.in example and the symlink genrule workaround, then inspect how rules_distroless handles Debian packages without running postinst scripts. Use the gdal-bin installation and ogr2ogr --version failure as the reproduction case. Done would be a documented best practice or supported generic handling for libraries installed through update-alternatives.

Written by the indexing model from the issue text.