Unify Span/Memory slicing exceptions

[MihaZupan]

Fixes #115239
Fixes #53622
Fixes #90939

We no longer report the "start" parameter name in these exceptions.

We could keeep it in the .Slice(int) overloads (no explicit length), but we were already inconsistent there too since Span doesn't report the parameter, but ReadOnlySpan does.

[Copilot]

Pull Request Overview

This PR unifies the exception behavior for Span/Memory slicing operations by removing parameter name disclosures and consolidating bounds checking into MemoryExtensions.ValidateSliceArguments.

• Replaces legacy bounds checking (with TARGET_64BIT conditionals) with calls to MemoryExtensions.ValidateSliceArguments or MemoryExtensions.SliceArgumentsAreValid.
• Updates multiple methods and tests to throw exceptions without including parameter name details.

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
System/String.cs	Replaces custom bounds checking with MemoryExtensions.SliceArgumentsAreValid.
System/String.Manipulation.cs	Updates Substring slicing bounds check to use ValidateSliceArguments.
System/Span.cs	Replaces legacy conditional bounds checks with a unified ValidateSliceArguments call.
System/Runtime/InteropServices/MemoryMarshal.cs	Updates bounds check to use ValidateSliceArguments.
System/ReadOnlySpan.cs	Replaces conditional checks with a unified ValidateSliceArguments call.
System/ReadOnlyMemory.cs	Updates slicing bounds checking and exception throwing to the new unified approach.
System/Range.cs	Removes parameter name from ArgumentOutOfRange exception.
System/MemoryExtensions.cs	Adds SliceArgumentsAreValid and ValidateSliceArguments methods to encapsulate bounds checking.
System/Memory.cs	Replaces legacy bounds checks with ValidateSliceArguments calls.
System/ArraySegment.cs	Updates argument validation to use SliceArgumentsAreValid.
Tests	Adjust tests to expect exceptions without a parameter name.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[jkotas]

This introduces two more levels of inlining. We may want to check that it is not regressing code quality.

[MihaZupan]

Total bytes of delta: -5703 (-0.01 % of base)

I did spot check a couple diffs from PMI MihuBot/runtime-utils#1079, not seeing anything egregious (not seeing a lot less inlining).

As expected there's a bunch of small size improvements from cold blocks sharing the same throw helper (just Throw() instead of Throw() and Throw(int)).
E.g. MemoryExtensions:Trim[int], GetRedactedPathAndQuery, Json.Serialization.Converters.Int128Converter:WriteCore

Most diffs are from string.Substring(int, int) getting inlined more.
E.g. ParseTimeZoneIds, EncodingTable:GetEncodings(), TimeZoneInfo:.ctor

And a handful of cases where a helper is no longer being inlined, e.g.
Http3Frame:TryReadIntegerPair

[MihaZupan]

StringSegment appears to have more correct validation here w.r.t. reporting parameter names and it's relying on ReadOnlySpan for it in a few places, but the ambiguous validation in span/memory doesn't seem to be reachable from it.

I'll have to tweak that one, unless we'd be fine with just throwing a less informative argument exception.
(it could also probably be made a bit cheaper since we're currently validating stuff twice in some cases)

Edit: Kept StringSegment behavior the same, just also using the more efficient checks.