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

**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.