Fingerprint out of root targets

[krtab]

This PR partially fixes #15203 and #12266 but this is admitedly a bit hackish, let me know how you want to proceed with it.

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[krtab]

This is the hack described in #12266 (comment) and hence has the same caveats that #[path] attributes won't be supported.

[weihanglo]

Thanks for helping with this issue!

As you've said, this is hacky. Some high-level feedback:

• PathSource::list_file (which then calls _list_files) is used in computing fingerprints for build scripts and cargo doc, as well as determining what is going to be packaged into cargo package. During packaging, any file outside the package root will not be packed into the resulting .crate file. Cargo even emits a warning when the situation is detected. With this change, cargo-package starts including those files again. This is undesired, not even mention that where should their path be in the .crate tarball.
• How do this hack know what really needs to track? It simply looks at the directory the target source file is in and assume it always at the root directory with all other relevant files. Yeah it cannot handle #[path] we already knew, but it also doesn't respect git directory and include/exclude options. It may accidentally include more files they necessary.

To me I still think depinfo from rustdoc is a more sustainable approach. We might want to put more effort on that route than sorting out a hack.

Some other alternatives are on user side, like breaking them into sub packages for reasonable reuse.

[Vrixyz]

• allow me to link rustdoc: add support for --emit=dep-info rust#91982 which is the tracking issue for the "sustainable" approach mentioned

[weihanglo]

Thanks! It is linked in #12266 (comment), which also calls out a relevant Cargo issue #9931.

[weihanglo]

Also note that the issue is not labeled as S-accepted. It is recommended to discuss designs in issues rather than in pull requests.