Dependency graph cycle detection seems too eager, finding cycles where there are none

[sil2100]

Description

Still fresh to the tooling, but this is something I encountered when trying to test-rebuild some things against a new glibc. Scenario: in a PR I was updating glibc and wanted to rebuild binutils (and others) against it in a single PR. Without an explicit glibc-dev dependency (only via build-base), the local glibc was not used. After checking the dag graph code, I added an explicit glibc-dev dep to the build environment. This resulted in a cycle being detected and erroring out:

failed to bundle: targets: cycle detected: binutils:2.43.1-r3@local -> glibc:2.40.9000-r0@local, caused by: glibc:2.40.9000-r0@local -> bash:5.2.37-r2@local -> binutils:2.43.1-r3@local

...which feels to me incorrect, caused by the checker being over-eager. binutils has a glibc-dev dependency, which comes from the glibc source, but the only package from glibc which has the bash runtime dependency is posix-libc-utils, which is not installed when glibc-dev is installed. It simply is part of the glibc set of packages. I feel as if this should not be considered a cycle. Runtime dependencies should matter only for the packages that are installed as part of the chain.

Open to discussion.