Otherwise, the test will fail for all forks sending PRs too!

On some local cases, I found out that if Description (for example) contained multi-line text, it would cause other metadata values to be skipped and moved to another item altogether.

This makes sure that updating that metadata never interferes with the rest of the metadata.

Some code paths were failing if files didn't exist, which is expected when running nugetize since it avoids the costly compilation steps for large packages.

When packing "for real" files will exist and be checked always by the NuGet packaging API anyway.

The new --quiet option would skip rendering the MSBuild output from `dotnet msbuild`, which is now on by default since it's generally useful.

Leverage that same mechanism for our own built-in properties. This also means we don't need to explicitly run restore, since users can just pass `-r` and we'll pass-through that to MSBuild to do its thing.

Also make the syntax for binlog arg the same as MSBuild (`-bl`) so that we're effectively a superset of that switch (we also automatically attempt to open the log file after the run, if msbuildlog.com is installed).

Also, the --version switch will cause us to also render MSBuild logo/version info (without it, we pass -nologo instead), unifying the experience there too.

If provided by a source control provider (i.e. SourceLink).

Not for nugetizer itself but for how we build this repo, rather.

We were using the options prototype syntax for boolean switches, rather than value-based arg.

Since the nugetizer targets write to it from MSBuild, it should be an absolute path so we don't accidentally write it all over the place.

The filtering of the resulting MSBuild items file was too messy and kinda pointless anyway. Best to make it more focused and precise instead.

We were previously only updating the metadata item with the properties if it didn't exist before. By moving the setting of the multi-line properties afterwards, we broke the initial condition, which would cause extenders using <PackageMetadata> explicitly to be overriden improperly.

Since it would typically be a user error, but we still want to test that code path.