Improve the debugging and contribution story of published nuget packages

_This issue is opened based on @diverdan92's suggestion from https://github.com/NuGet/Home/issues/7087_

When developing a nuget package, it is a standard scenario to have a separate application solution which uses this package, particularly for open source projects. Here's the scenario, and I'm going to use an actual project name for easier naming :

- Project [Uno.UI](https://github.com/nventive/Uno) has a package published on nuget.org (e.g. v1.0.0), has SourceLink enabled.
- The developer of [Uno.WindowsCommunityToolkit](https://github.com/nventive/Uno.WindowsCommunityToolkit) which is using the published v1.0.0 vesion of the Uno.UI nuget package.
- While developing the **Uno.WindowsCommunityToolkit**, the developer finds an issue in **Uno.UI**, is _not_ able to step into the code using SourceLink. Note that there's very limited support for intellisense, which is expected with the current tooling, as there's no way for VS to get additional context from a single source file.
- When the developer of **Uno.WindowsCommunityToolkit** wants to alter the code of the **Uno.UI** v1.0.0 package to fix the issue and make a PR back to **Uno.UI**, he's stuck there with current tooling, as there's out-of-the-box way to do this without jumping through hoops.

Currently, there are two possible ways to work around this:
- Integrate the whole **Uno.UI** solution into the **Uno.WindowsCommunityToolkit** solution, replace all the `` in **Uno.WindowsCommunityToolkit** to use `` instead. This can also work the other way around. This solution is particularly cumbersome when the solution contains solution-specific artifacts and configurations, and there's no automated tooling for migrating `PackageReference` to `ProjectReference`.
- Use trick [like this one](https://github.com/nventive/Uno/blob/3b8073c8f86ef5a6711e5aaadccc0ab121b31034/src/Uno.CrossTargetting.props#L90) to override the global (or local but this does not change much) nuget cache with new binaries and symbols. While this solution works, it confuses debuggers (Xamarin.Android and iOS, particularly) and it pollutes the nuget cache with custom binaries.

Having a better end to end developer experience for libraries development, including the support and external contribution scenarios would simplify a lot the development in the .NET ecosystem.