Add unchecked math inherant impls to integers

[CAD97]

This exposes the unchecked_add and unchecked_sub intrinsics on integers.

If we agree we want this, I'll make a tracking issue and point the #[unstable] attributes at it.

This would be used by #62886 at a minimum.

[rust-highfive]

r? @joshtriplett

(rust_highfive has picked a reviewer for you, use r? to override)

[Centril]

N.B. the discussion in #59148. cc @rkruppe @ubsan

[CAD97]

Honestly, I'd be fine having these be feature = "rustc_internals", issue = "0" forever; however, it's a lot simpler to use them where they're actually beneficial as methods (or functions) that are actually typed rather than the intrinsics.

They'd be less easy to reach for if they weren't available as methods and had to be used as e.g. usize::unchecked_add, if that would make it easier to swallow.

[Centril]

Honestly, I'd be fine having these be feature = "rustc_internals", issue = "0" forever; however, it's a lot simpler to use them where they're actually beneficial as methods (or functions) that are actually typed rather than the intrinsics.

As long as we're using issue = "0" I think it won't need sign-off from any team and then you also don't need to create a tracking issue. I think that's a good idea if your goal is simply to use these internally though it might be preferable if you cherry-pick this PR into the other one + perf numbers to show that the added unsafe is actually beneficial.

[joshtriplett]

What's the purpose and use case for these functions, as opposed to functions guaranteed to have wrapping semantics?

[strega-nil]

@joshtriplett better optimization -- see the original PR to add the intrinsics.

[JohnCSimon]

Ping from triage
@CAD97 @joshtriplett This has sat idle for nearly a week. I'm not sure what else needs to happen for this PR?

Thanks.

[CAD97]

I'm going to close this and include it in the use case for now as an issue = "0" stdlib-internal interface.