const-stabilize the unchecked_{add,sub,mul} *intrinsics*

[scottmcm]

This is only the intrinsics, which aren't exposed anywhere, so I think we can just do this without an FCP.

The behaviour of these is well understood, have been implemented for ages, and don't offer any new functionality to const fns -- it would be completely legal for them to be implemented via wrapping_add, since we don't promise to catch all UB.

(Sending this because I was working on something else where I wanted to use unchecked_sub for a length in a const fn, and it complained at me.)

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

r? @oli-obk for const-eval(?) decision here

[bors]

☔ The latest upstream changes (presumably #97873) made this pull request unmergeable. Please resolve the merge conflicts.

[oli-obk]

We have never const-stabilized an intrinsic without also stabilizing a function using it before. As per the big banner at the top of the file, intrinsics need to be signed off by the lang team, and I don't have a good argument for stabilizing it without a const fn that needs it.

[oli-obk]

Closing this as per my comment above