Parser for actual MSBuild Property option syntax

[baronfel]

Description

Fix issues forwarding a complex variation of allowable input for the MSBuild -p (Property) option, which is parsed, escaped, and forwarded to MSBuild as a feature of the SDK.

Customer Impact

In AzDO (and likely other scenarios), users-defined properties are passed with a single -p option, in a semicolon-delimited list of key/value pairs. Enforcement/unification of the property option in the 6.0.3xx series of SDKs introduced a regression in this parsing that resulted in malformed key/value pairs being passed to user builds. The most common effect of this was to prevent the build from running due to invalid CLI argument syntax.

Closes #27059

The SDK property option didn't know about the semicolon- and comma-delimited forms of MSBuild properties. This adds an actual parser to validate this shaping, so that we can intelligently do the semi-colon escaping that we aimed to do originally, without also inadvertently escaping the semicolon-delimited property list use case for -p.

The core tension here is the SDK wants to do escaping of semicolons inside property values so that those properties aren't interpreted incorrectly by the MSBuild CLI parser. This is a historical pain point for users, which is why we started doing this back in the day. This has been done through the Property Option in the SDK, and over time our parsing of the value portions of this CLI flag has grown.

Regression

Yes

Risk

Medium. The fix was to create a new parser for the syntax of the MSBuild Property option, versus the naïve string splitting that was done in the past. This is a nontrivial amount of code.

Testing

The new tests for this forwarding now cover a few additional cases that I verified with Rainer and Ben - quoted property values that contain semicolons and spaces, and unquoted values signaling a new property name. Automated testing was done with all known variants of the -p argument syntax. The existing cases were:

• single key/value (X=Y)
• single key with quoted value (X="Y")
• single key with quoted semicolon delimited value (X="A;B;C")

And the following cases were added:

• single key with whitespace values (x=" a y value")
• multiple key/value pairs, semicolon delimited, with values being of all of the above types (x=y;x2="y";x3="a;b;c";x4="a ;b ;")

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[nagilson]

I tried to break it from many different angles and could not break it. If Rainer has validated it from the MSBuild syntax side, LGTM. Not sure if you need approval from a servicing person as well.

[dsplaisted]

LGTM 👍