optimize `cargo nextest list --list-type binaries-only` to avoid unnecessary setup work

`cargo nextest list --list-type binaries-only` appears to do a substantial amount of work that is not needed for its current behavior. Today, the `binaries-only` path still eagerly: - loads config and profile, - parses filtersets and builds a `TestFilter`, - initializes shared base state that includes Cargo metadata / `PackageGraph` setup, and - in some cases resolves build platform metadata that is only needed for later phases. However, the `binaries-only` branch ultimately just writes the `BinaryList` and does not use the profile or test filter. Relevant code paths: - `cargo-nextest/src/dispatch/core/list.rs` - `cargo-nextest/src/dispatch/core/base.rs` Measured on the nextest workspace itself, warm cache, macOS: - `cargo nextest list --list-type binaries-only`: ~473 ms - `cargo nextest list --list-type binaries-only --cargo-metadata ...`: ~330 ms - `cargo nextest list --list-type binaries-only --binaries-metadata ...`: ~194 ms - `cargo nextest list --list-type binaries-only --cargo-metadata ... --binaries-metadata ...`: ~52 ms This suggests there is a meaningful win available from making the `binaries-only` path lazier: - branch earlier in `exec_list`, - skip config/profile/filterset construction for `binaries-only` while preserving current semantics, and - defer `cargo metadata` / `PackageGraph` creation when reused `binaries-metadata` is already sufficient. One open question is whether `binaries-only` should continue to ignore filtersets and profile-driven config. This issue is about preserving current behavior and avoiding dead work, not changing semantics. Related: - #229 - #154