Making numerical formatting specifiers more consistent

[stephentoub]

Today 'R'/'r' aren't supported with integral types but are with floating point, and 'X'/'x' aren't supported with floating point but are with integral types. Related to both #65634 and the generic math support, where INumber<T> inherits ISpanFormattable and thus we should expect format specifiers to be used with arbitrary numerical types, we should allow all of these specifiers to be used, regardless of integer vs floating point. 'R'/'r' for integers can just be treated as 'G'/'g', respectively, and 'X'/'x' for floating point is covered by #1630.

(Discussed in API review on 4/5/2022.)

cc: @tannergooding

[ghost]

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

Issue Details

---

Today 'R'/'r' aren't supported with integral types but are with floating point, and 'X'/'x' aren't supported with floating point but are with integral types. Related to both #65634 and the generic math support, where INumber<T> inherits ISpanFormattable and thus we should expect format specifiers to be used with arbitrary numerical types, we should allow all of these specifiers to be used, regardless of integer vs floating point. 'R'/'r' for integers can just be treated as 'G'/'g', respectively, and 'X'/'x' for floating point is covered by #1630.

(Discussed in API review on 4/5/2022.)

cc: @tannergooding

Author:	stephentoub
Assignees:	-
Labels:	area-System.Numerics, untriaged
Milestone:	-

[tannergooding]

This one should be relatively straightforward for R, it just needs to be treated the same as G for the built-in Integer types.

The hexadecimal support for floating-point types is a bit more complex (namely due to handling a different set of suffixes) but is tracked by #1630.