Improve developer workflow for transitive dependency pre-builts

Example of issue described: https://dev.azure.com/dnceng/internal/_git/dotnet-aspnetcore/pullrequest/35509

Currently the pre-built report produced by Arcade infrastructure states the following information about the pre-built:
- name
- version
- project restoring the pre-built

In cases where the pre-built is a transitive dependency, the developer resolving the pre-built does not have enough information from pre-built reports to deduce what exactly is causing the issue (unless they are aware of the dependency relationship in this particular case).

Under normal workflow the developer would discover the issue through CI (for example, a build for a dependency update PR) and would need to build the repository / project locally, look inside the `project.assets.json` file mentioned in the pre-built reports and find the link between the transitive dependency and the direct dependency referencing it. For smaller repositories this is not a big deal, but for bigger ones like `aspnetcore` or `runtime` the build itself could take a while and might require additional setup. Moreover, if the issue is in an internal mirror, the setup required to build locally is enlarged even more.

It would be beneficial for this workflow if the pre-built report either provided some additional information related to how the dependency was resolved or the Arcade infrastructure exposed some artifact as part of CI that would help with this investigation