cpp_info should contain relative path to individual libraries

[memsharded]

Right now, lib_paths and libs are quite decoupled. It should be more deterministic to express which library belongs to which path. This would also be aligned with @vector-of-bool libman proposal at https://github.com/vector-of-bool/libman

[vector-of-bool]

This kind of boils down to an impedance mismatch between the way Conan (and many tools) represent libraries versus how libman wants to consume them. A library has:

1. A name
2. One or more #include directories
3. One or more "linkables" (library files, as specified by this issue)
4. Public usage dependencies
5. Private link-time dependencies

When a package provides a single "library," Conan's representation is fairly sufficient with a few tweaks, given that the CppInfo object has includes, libs, and lib_paths. For packages which expose multiple linkables and/or multiple #include trees, the communication begins to break down.

In my repository, I'm working on a LibMan generator which looks into the UserInfo for a dependency in order to generate the metadata needed for the build system (otherwise tried to auto-generate it from CppInfo). It may be useful to experiment on a UserInfo solution might look like before moving it to the CppInfo object?

[memsharded]

This is being addressed by recent CPS work, adding location fields to cpp_info, latest Conan 2.8 contains this cpp_info.location field.