Better `buildInputs` handling (non-Rust libs)

Hey,
First off, thank you so much for writing and maintaining this!

I've been happy to use nci in [nixops4] and [nix-bindings-rust].

Since these projects have a bunch of crates with C library dependencies, I've
- created a module in [an option](https://flake.parts/options/nix-bindings-rust.html#opt-perSystem.nix-bindings-rust.nciBuildConfig) to make nix bindings easy to consume in other projects (like `nixops4`)
- made it a [fairly general solution](https://github.com/nixops4/nix-bindings-rust/blob/0.2.0/input-propagation-workaround.nix)

I wouldn't recommend to adopt the contents of that module as they are, because it doesn't proper input propagation beyond depth 1 of dependents, which would be pretty confusing to users who need that. (E.g. native-tls -> openssl-sys works, but reqwest -> native-tls won't know about openssl).

It'd probably be easier to reimplement this as an integral part of nci and actually take all dependency links into account in one go.
I feel like my module code consists of 20% solving the problem, 40% data, and another 40% integration struggle you won't have.

If you'd like to have a more declarative way to declare library inputs, it'd be great to have something a bit like `crateInputMapping`.
Let me know what you think :)

[nixops4]: https://github.com/nixops4/nixops4
[nix-bindings-rust]: https://github.com/nixops4/nix-bindings-rust