Expose missing BinaryPrimitives APIs

[tannergooding]

This resolves #72107

[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, to 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.

[ghost]

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

Issue Details

---

This resolves #72107

Author:	tannergooding
Assignees:	-
Labels:	area-System.Buffers, new-api-needs-documentation
Milestone:	-

[stephentoub]

Is there anywhere we should be using these?

[tannergooding]

I'm not aware of any places where we're using Int128/UInt128 ourselves yet.

Looks like we can switch to using IntPtr/UIntPtr in EventPipe. I didn't transitively look at other calls (BinaryReader.ReadInt64 or XmlBinaryReader.GetInt64), however.

[tannergooding]

Fixed the docs and updated relevant places to use the new BinaryPrimitives APIs where applicable.

[tannergooding]

Failure is #82055, this can be merged once it gets sign-off.

[dakersnar]

LGTM. Any specific logic in the tests that could use a deeper pass? Also, will we want these APIs on the new Decimal types?

[tannergooding]

Any specific logic in the tests that could use a deeper pass?

None come to mind. These are relatively straightforward APIs.

Also, will we want these APIs on the new Decimal types?

Probably not without explicit user ask. Users can achieve the same thing by reading the raw bits and calling DecodeDecimal/DecodeBinary (there is also a layering issue with regards to BinaryPrimitives being in corelib).