[FEATURE] Define a VPM manifest field which requests NuGet packages as a dependency

[bdunderscore]

Is your feature request related to a problem? Please describe. VRCSDK currently pulls in several general-purpose C# libraries, such as System.Collections.Immutable and Harmony. While it's helpful to be able to depend on these, there's not a good solution for pulling in additional C# libraries from NuGet. I could bundle them - but if any other VPM package, or in the future the VRCSDK itself, adds that package, it'll result in a conflict and errors that aren't reasonably resolvable by users.

Describe the solution you'd like Add a "nugetDependencies" leaf to the VPM manifest format:

{
  "name" : "com.mydomain.avatarTool",
// ...
  "vpmDependencies" : {
    "com.vrchat.avatars" : "3.1.0"
  },
  "nugetDependencies" : {
    "System.Collections.Immutable": "[8.0.0,9.0.0)",
    "System.Text.Json": "(,9.0.0)"
  },
// ...
}

When installing packages, VCC should:

1. Determine a common set of versions which satisfy all locked packages and all local packages (this latter part is critical for local VPM package development).
2. Fetch and install these nuget dependencies as a dedicated local package.
3. Remove obsolete nuget dependencies (optionally)

Nuget dependencies should be locked, as with local dependencies.

Describe alternatives you've considered I've considered bundling library dependencies. As mentioned above, this will result in conflicts if multiple packages pull in the same dependency, or if the VRCSDK adds additional dependencies in the future.

Additional context

[orels1]

Funnily enough, I have not seen issues with harmony in unity 2022 as long as you turn off "auto reference" on the imported dll only the files in the relevant assembly will reference it so i had 3 harmony instances in the project without any conflicts.

This is an interesting proposal, especially because dealing with nuget packages in unity is just a really bad experience overall

[bdunderscore]

Importing the same assembly from multiple packages would result in the diamond dependency problem if you have a third package depending on both, so it's not a great solution for framework packages like NDMF :/

[orels1]

The main concern is that users are actively force-upgrading dependencies every day in VCC, and in that case if installing a completely unrelated package suddenly bumps a nuget dep of some other package to an incompatible version and breaks it for no reason - that is potentially a worse user / support experience.

So this becomes a tradeoff of "avoiding 2 different versions imported by a 3rd package" vs "constantly running a risk of upgrading something unrelated".

To me it feels like both of those have strong arguments to be made from both dev/support, as well as the user experience side.

[orels1]

I am also not sure if turning VPM also into basically a nuget package manager is something in the realm of what VPM should be doing. That's basically building another dependency graph, fetching, caching, parsing for a totally different package management system.

[orels1]

But either way, this needs internal discussion. I'll share any thoughts we have on this when there is stuff to share