TODO: rewrite semanticReleaseConfigDotnet.ts and related files to improve NuGet functionality

[BinToss]

semanticReleaseConfigDotnet.ts

NuGet clients and server APIs do not implement --dry-run functionality. The request for it has been open for three years with no progress. So, I have to improvise effectively-equivalent functionality out of existing NuGet features.

• If the authorization token DOES NOT have permission to push new versions/packages for the given package ID, fail the release.
• If the package ID already has the new version listed, fail the release.

Both are accomplished by the following:

• grab the new version during Prepare
• copy our pre-made, lightweight v0.0.1-DUMMY dummy package. Overwrite its PackageID with the real ID.
• query the NuGet source (i.e. package registry/server) for the package ID and check the existing package versions for the "new version" we want to publish.
• dotnet nuget push ./publish/${PackageId}.0.0.1-DUMMY.nupkg -source NugetSourceName --api-key private_token --skip duplicate.

--skip-duplicate tells the Source and client it's okay if the dummy package already exists.
If we do not receive an error, proceed. If the error is 403, then the token was denied access. This can happen if "the token is invlaid, unrecognized, or was denied access to the Source" (private, GitLab, GitHub), "the token has Write or Delete permission for one or more packages, but was used for an package ID it's not authorized to access" (NuGet.org, private), or "the token was created without Write or Delete permissions" (any source). If any error occurs, including 403, add the error to an array.

Repeat for every given PackageId, per each NuGet source. Each PackageId will need one auth token per Source.

After all test pushes finish and if the error array is not empty, throw new AggregateError(errors) and halt the release procedure. Otherwise, proceed with the rest of the release procedure.

I'll need:

• new FileInfo class for MSBuildProject constructor parameter. Ensures the parameter passed to the constructor represents an existing file. Dirent is close, but requires extra steps to get. Our TypeScript/JavaScript runtime will not read the project file's contents directly—we delegate that to Dotnet CLI's dotnet msbuild -getProperty:PropertyName0 -getProperty:PropertyName1 ... to evaluate MSBuild properties.
• NugetRegistryInfo constructor with MSBuildProject parameter
• ...

[BinToss]

I have an issue for this already open...
Closing in favor of #408