Add generic Random NextInteger/NextBinaryFloat APIs

[stephentoub]

Adds generic numeric APIs to System.Random:

• NextInteger<T>()
• NextInteger<T>(T maxValue)
• NextInteger<T>(T minValue, T maxValue)
• NextBinaryFloat<T>().

Fixes #75431

[Copilot]

Pull request overview

This PR adds new generic numeric APIs to System.Random to generate random integer values for any IBinaryInteger<T> and random IEEE-754 binary floating-point values for any IBinaryFloatingPointIeee754<T>.

Changes:

• Add Random.NextInteger<T>(), Random.NextInteger<T>(T maxValue), and Random.NextInteger<T>(T minValue, T maxValue) with fast paths for common integer types and generic rejection-sampling fallbacks.
• Add Random.NextBinaryFloat<T>() with fast paths for float/double/NFloat and a generic implementation that guarantees results in [0, 1).
• Update reference assembly API surface and add unit tests covering edge cases, large ranges, and derived Random dispatch behavior.

Show a summary per file

File	Description
src/libraries/System.Private.CoreLib/src/System/Random.cs	Implements the new generic integer and binary-float generation APIs, including fast paths and fallbacks.
src/libraries/System.Runtime/ref/System.Runtime.cs	Exposes the new Random APIs in the System.Runtime reference assembly.
src/libraries/System.Runtime/tests/System.Runtime.Extensions.Tests/System/Random.cs	Adds coverage for argument validation, boundary/range behavior, and derived Random virtual dispatch; also introduces helper numeric wrapper types for custom reference-type coverage.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 3

[tannergooding]

This feels like it needs to throw if we are preventing some NeverPositiveInteger from working.

[tannergooding]

This comment seems incorrect and/or misleading.

The underlying type can use whatever storage format it wants, nothing prevents some bool signed; uint magnitude; value from functioning.

Rather, the consideration is that it must behave as if it were a two's complement value with all values in range being representable (see also BigInteger), which is a general expectation of IBinaryInteger<TSelf> due to APIs like lzcnt, popcnt, tzcnt, shift, etc

This is because we functionally determine the number of bits needed for [0, MaxValue] and then use T.ReadLittleEndian to construct the value and that won't work correctly for something that has non-linear distribution or which violates other IBinaryInteger expectations

[tannergooding]

nit: The bit arithmetic here is efficient, but it's also harder to read

Can we either add the appropriate comments or cast to uint and do the normal operation (i.e. (bitLength + 7) / 8) so the JIT optimizations will kick in?

[tannergooding]

This seems superfluous, a type is "invalid" and will exhibit undefined behavior if MaxValue isn't actually MaxValue

[tannergooding]

Some minor nits, but overall looks good.

I think we should remove the Debug.Assert from the public API and validate it properly however, since we'll never trigger that assert ourselves but a user might.