[release/9.0] Remove string.Trim{,Start,End}(ReadOnlySpan<char>) ref-API

[bartonjs]

Manual backport of #108537 to release/9.0

Customer Impact

• Customer reported
• Found internally

Customers who have existing extension methods, string.Trim(string) (or TrimEnd, or TrimStart) find that their extension methods no longer get called after upgrading to .NET 9. These extension methods almost always want to turn "prefixinfixsuffix".TrimEnd("suffix") into "prefixinfix", but our new method public [instance] string [string::]TrimEnd(ReadOnlySpan<char> value) has higher binding order over their extension method, and it produces the result "prefixin", as it is instead treating the "suffix" as a set of characters to remove from the end of the string (equivalent to "prefixinfixsuffix".TrimEnd('s', 'u', 'f', 'f', 'i', 'x'), rather than a specific sequence of characters.

Regression

• Yes
• No

Customers who had applicable extension methods experience these new overloads as a regression from previous versions.

Testing

As the tests for these methods no longer compile, they are also removed.

Risk

This change is breaking. Any callers who specifically call Trim, TrimStart, or TrimEnd with a ReadOnlySpan<char> will have to change their code. Two such sites were identified in dotnet/wpf and have already been mitigated.

Callers which were calling the new methods via params syntax will not experience a runtime break with this change, as it removes the ref but not the implementation (yet). When those callers recompile they will switch (back) to the Trim(params char[]) overload with no action required on their part.

As this change only removes things, the risk that the change does not solve the problem is low. The risk that it requires unanticipated followup in dotnet/runtime is also low. While other dotnet/* repositories have been checked for breaks, some may have been missed, and they will break automatic ingestion and have to be fixed as they surface.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[stephentoub]

If we haven't already, I assume our intent is to follow-up for net10.0 with a change to remove these and delete the source impl?

[bartonjs]

The current intent is both main and ~9.0.1, just letting prebuilt things get through a cycle of the method "not being there" without the MissingMethodException.

[bartonjs]

Breaking change documentation seeded at dotnet/docs#43032.

[carlossanlop]

/ba-g failure is preexisting