Rollup merge of #113510 - ink-feather-org:const_ptr_transmute_docs, r…

…=RalfJung

Document soundness of Integer -> Pointer -> Integer conversions in `const` contexts.

see this [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Soundness.20of.20Integer.20-.3E.20Pointer.20-.3E.20Integer.20conversions)

r? `@RalfJung`

With this slice `Iterator`'s should be able to be made const once the const Trait reimplementation is done.

library/core/src/intrinsics.rs

@@ -1130,7 +1130,10 @@ extern "rust-intrinsic" {
     /// may lead to unexpected and unstable compilation results. This makes `transmute` **incredibly
     /// unsafe**. `transmute` should be the absolute last resort.
     ///
-    /// Transmuting pointers to integers in a `const` context is [undefined behavior][ub].
+    /// Transmuting pointers *to* integers in a `const` context is [undefined behavior][ub],
+    /// unless the pointer was originally created *from* an integer.
+    /// (That includes this function specifically, integer-to-pointer casts, and helpers like [`invalid`][crate::ptr::invalid],
+    /// but also semantically-equivalent conversions such as punning through `repr(C)` union fields.)
     /// Any attempt to use the resulting value for integer operations will abort const-evaluation.
     /// (And even outside `const`, such transmutation is touching on many unspecified aspects of the
     /// Rust memory model and should be avoided. See below for alternatives.)