Fix MSBuild property values containing '/dotnet' misinterpreted

[chris-peterson]

Summary

Fixes #53662

MSBuildArgs.AnalyzeMSBuildArguments creates a synthetic System.CommandLine.Command named "dotnet" to re-parse forwarded MSBuild arguments.
System.CommandLine treats /<command-name> inside option values as a reference to the command itself, so any /p: property value containing
/dotnet (e.g., /p:DockerImage=registry.example.com/myproject/dotnet) causes the parser to silently reject the token. The rejected value is then
forwarded to MSBuild as a bare argument (without the /p: prefix), which MSBuild interprets as a project file path — resulting in MSB1009: Project file does not exist.

This was introduced by #49526.

Reproduction

mkdir repro && cd repro
dotnet new console
dotnet msbuild -p:MyProp=something/dotnet   # MSB1009
dotnet msbuild -p:MyProp=something/other    # works

Fix

Rename the synthetic command from "dotnet" to "__msbuild-args-analysis__" so it is unlikely to collide with values that appear in real MSBuild
property arguments. Only the command's own name triggers this System.CommandLine behavior.

Test

Added PropertyValuesContainingSlashDotnetArePreserved regression test covering both /p: and -p: forms.

[baronfel]

I think this would work around the issue, but the more concerning thing to me is why S.CL has the parsing behavior is does. That feels like a foot gun to me.

[chris-peterson]

@baronfel

why S.CL has the parsing behavior is does. That feels like a foot gun to me.

I agree 👍

I ended up going further down the rabbit hole:
dotnet/command-line-api#2789

might make sense to keep this change too though given it might take a while for the fix to percolate