Workspace feature resolution for multiple binaries

## Description

It's somewhat related to the issue I have here: https://github.com/axodotdev/cargo-dist/issues/1460

I now modified my approach to instead of attempting to statically link HDF5, I dynamically link it, but then I distribute two binaries, one that needs a system HDF5 installation and one that doesn't. I use a feature to guard the HDF5 dependency.

Then I run into the yet unsolved issue of [workspace feature unification](https://github.com/rust-lang/cargo/issues/14774) there's a [(merged) RFC as well](https://github.com/rust-lang/rfcs/blob/master/text/3692-feature-unification.md) but it is a hard problem. If I just build with `cargo build -p plotinator3000` I get a binary that does not link to hdf5, but if I build with `cargo build --bins` then both link to hdf5 because of the workspace feature unification issue.

This is where `dist` comes into the picture because how does `dist` build the binaries? Evidently through something like `cargo build --bins` because both binaries built by `dist` link to `HDF5`.

e.g. in [this action log](https://github.com/luftkode/plotinator3000/actions/runs/13098730971/job/36544319730?pr=174) I build a workspace with multiple binaries (`plotinator3000` and `plotinator3000-h5`), such that users can run a binary that doesn't require an HDF5 dynamic library on the system if they don't need HDF5 support. The example is the apple build but it is the same for all builds.

```text
plotinator3000 (aarch64-apple-darwin)
┌────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────┐
│ Category ┆ Libraries │
╞════════════════════╪═════════════════════════════════════════════════════════════════════════════════════════╡
│ System ┆ /usr/lib/libSystem.B.dylib │
│ ┆ /usr/lib/libbz2.1.0.dylib │
│ ┆ /usr/lib/libiconv.2.dylib │
│ ┆ /usr/lib/libobjc.A.dylib │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Homebrew ┆ /opt/homebrew/opt/hdf5/lib/libhdf5.310.dylib (hdf5) │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Public (unmanaged) ┆ │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Frameworks ┆ /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit │
│ ┆ /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices │
│ ┆ /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon │
│ ┆ /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync │
│ ┆ /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation │
│ ┆ /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics │
│ ┆ /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices │
│ ┆ /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo │
│ ┆ /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation │
│ ┆ /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Other ┆ │
└────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────┘
plotinator3000-h5 (aarch64-apple-darwin)

┌────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────┐
│ Category ┆ Libraries │
╞════════════════════╪═════════════════════════════════════════════════════════════════════════════════════════╡
│ System ┆ /usr/lib/libSystem.B.dylib │
│ ┆ /usr/lib/libbz2.1.0.dylib │
│ ┆ /usr/lib/libiconv.2.dylib │
│ ┆ /usr/lib/libobjc.A.dylib │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Homebrew ┆ /opt/homebrew/opt/hdf5/lib/libhdf5.310.dylib (hdf5) │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Public (unmanaged) ┆ │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Frameworks ┆ /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit │
│ ┆ /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices │
│ ┆ /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon │
│ ┆ /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync │
│ ┆ /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation │
│ ┆ /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics │
│ ┆ /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices │
│ ┆ /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo │
│ ┆ /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation │
│ ┆ /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Other ┆ │
└────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────┘
```

## Proposed solution

If I could control the build to use `cargo build -p plotinator3000` and `cargo build -p plotinator3000-h5` then I achieve what I need without having to wait for the Cargo team to figure out and implement workspace feature unification configuration options.

This issue of HDF5 linkage is becoming more and more of an issue for my project, I really want to keep using `dist` because it is a major benefit, but if I can't solve this issue in a way that doesn't bother users, then I have to consider another approach. I'm very open to suggestions btw, maybe there's a much better approach that I'm totally missing.

Start by reproducing the workspace behavior with `cargo build --bins`, then compare it with `cargo build -p plotinator3000` and `cargo build -p plotinator3000-h5`; the linked Cargo feature-unification issue and RFC provide context. Done means dist can build the binaries independently so the non-HDF5 binary does not link HDF5 while the HDF5 binary does.

Written by the indexing model from the issue text.