Installing a dependency of a package mentioned in manifest fails to bring in transitive dependencies

Given the following example illustrating a common pattern of apt package dependencies: `libfoo-dev -> libfoo -> libbar`.

I have listed `libfoo-dev` in the manifest file that I pass to to rules_distroless' `apt.install()`.

When I include `libfoo-dev` in a container image I'm building, the dependencies (`libfoo` and `libbar`) are also included. So far, so good.

When I change this to include `libfoo` instead of `libfoo-dev`, I expect only `libfoo` and `libbar`, however, only `libfoo` is included, _not_ `libbar`. The dependency from `libfoo` onto `libbar` seems not to be encoded in the lock file generated by rules_distroless.

I can workaround this by explicitly mentioning `libfoo` (alongside `libfoo-dev`) in the manifest.

There is no error or warning associated with my use of `libfoo` in the container image (other than errors at runtime due to the missing `libbar`), nor is there any indication from rules_distroless that I somehow "forgot" to list `libfoo` (in addition to `libfoo-dev`) in the manifest.

Looking at the lock file, it seems to me that rules_distroless encodes all transitive dependencies of `libfoo-dev` as direct dependencies of that package, and that the nested/transitive dependency information is lost?

Start with rules_distroless' apt.install() handling of the manifest and generated lock file, using the libfoo-dev -> libfoo -> libbar example as the reproduction. Compare the recorded dependency structure for libfoo-dev and libfoo, then verify that selecting libfoo brings in libbar and that the behavior is covered by a regression test.

Written by the indexing model from the issue text.