Push to NuGet

[erri120]

Resolves #104

• adds a GitHub workflow for pushing packages to NuGet when a new tag is pushed to the repository
• uses a whitelist to manage which projects are being packaged
• fixes some dependencies
• adds a validation script that makes sure we're exporting every required local project
• adds a build step to the CI, this cleans up the logs and allows for better debugging

[erri120]

CI fails because fixes from #302 haven't been merged yet.

[Sewer56]

Looks good to me.
(Ignore CI failure, it's unrelated)

The only catch is that the approach would force the versions of all of the packages to be the same as the current project version; and (speaking from a perspective of a library author) I'm not sure if that's desirable.

Issue is, that it would lead to situations where a library e.g. NexusMods.Paths can go to a new major version e.g. 1.0.0 -> 2.0.0 despite there being no breaking changes in the library (or perhaps even none at all!).

Ideally I'd prefer to version the packages individually/manually in their respective .csproj files; but that also has issues. The project is monorepo (not an issue) with all of the dependencies as direct project references (a complication). Normally if you want to e.g. bring a fix from a dependency; you increment the version of the referenced project and increment your own version, and push. But with all projects in same solution it's hard to tell when that is the case from git logs; so it's a difficult situation. It's unlikely this will happen though so I'll lean on the side of YAGNI for this edge case. That said, I do find setting all built packages to the same version being problematic. I at least personally would prefer to have them manually versioned following proper semver.

I guess this is up for discussion.

[Al12rs]

I think that in either direction the solution should be automated or checked enough to avoid user error (forgetting to manually increase the package version etc).

In MO2 we have everything in separate repos with separate versioning and we have more grief having to manage each single thing. Errors and slip ups with versions can happen rather frequently (but we also don't have many checks or automations in place). We also missed not having some kind of tagging of the dependencies for each main application version, we had to do that manually making the release process very tedious.

For now I would venture to say that it might be ok like this. It could be changed later if it is needed.
I would err on the side of keeping things streamlined and simple for contributors.