core: Make Debug impl of raw pointers print metadata if present

[Enselic]

Make Rust pointers appear less magic by including metadata information in their Debug output.

This does not break Rust stability guarantees because Debug impl are explicitly exempted from stability:
https://doc.rust-lang.org/std/fmt/trait.Debug.html#stability

Stability

Derived Debug formats are not stable, and so may change with future Rust versions. Additionally, Debug implementations of types provided by the standard library (std, core, alloc, etc.) are not stable, and may also change with future Rust versions.

Note that a regression test is added as a separate commit to make it clear what impact the last commit has on the output.

Closes #128684 because the output of that code now becomes:

thread 'main' panicked at src/main.rs:5:5:
assertion `left == right` failed
  left: Pointer { addr: 0x7ffd45c6fc6b, metadata: 5 }
 right: Pointer { addr: 0x7ffd45c6fc6b, metadata: 3 }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[BoxyUwU]

r? libs
lol

[Noratrieb]

can you make this a core unit test instead?

[Enselic]

Sure no problem, I'll fix whatever my reviewer(s) ask me to do.

Would you mind elaborating a bit on why though? Do you prefer it as a core unit test because then the test can be run with a stage0 compiler, maybe? What I like about having it as a UI test is that --bless works when the output change.

Edit: Ok I can see we already have a bunch of related tests at library/core/tests/fmt/mod.rs, and one of them fails now. So I'll move my test there too.

[Enselic]

Done. I had to (with the current test code) add "regex" as an allowed library (dev-)dependency, but it is already present as an allowed rustc dependency, so it's fine I think.

[rustbot]

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

These commits modify the library/Cargo.lock file. Unintentional changes to library/Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.