API summary does not distinguish `init` accessor from `set`

[KalleOlaviNiemitalo]

Before #2205, CliAction had a public bool Exclusive { get; protected set; } property, and the API summary showed that as a read-only Exclusive property with a separate protected set_Exclusive method:

command-line-api/src/System.CommandLine/CliAction.cs

Line 14 in 02fe27c

public bool Exclusive { get; protected set; } = true;

command-line-api/src/System.CommandLine.ApiCompatibility.Tests/ApiCompatibilityApprovalTests.System_CommandLine_api_is_not_changed.approved.txt

Lines 19 to 23 in 02fe27c

	public abstract class CliAction
	public System.Boolean Exclusive { get; }
	public System.Int32 Invoke(ParseResult parseResult)
	public System.Threading.Tasks.Task<System.Int32> InvokeAsync(ParseResult parseResult, System.Threading.CancellationToken cancellationToken = null)
	protected System.Void set_Exclusive(System.Boolean value)

After #2205, CliAction has a public bool Terminating { get; protected init; } property, and the API summary shows that as a read-only Terminating property with a separate protected set_Terminating method:

command-line-api/src/System.CommandLine/Invocation/CliAction.cs

Line 18 in 104bb34

public bool Terminating { get; protected init; } = true;

command-line-api/src/System.CommandLine.ApiCompatibility.Tests/ApiCompatibilityApprovalTests.System_CommandLine_api_is_not_changed.approved.txt

Lines 225 to 227 in 104bb34

	public abstract class CliAction
	public System.Boolean Terminating { get; }
	protected System.Void set_Terminating(System.Boolean value)

That is, the API summary shows the protected accessor in the same way regardless of whether it is set or init.

Because replacing a set accessor with init is a breaking change, their API summaries should differ so that the API compatibility test can fail if such a change is made unexpectedly.