Format dyn Trait better in type_name intrinsic

[compiler-errors]

Noticed this in #103764 (though not related to that PR at all!)

trait Foo {
    type Bar;
}

fn main() {
    println!(
        "`dyn Fn(i32, i32) -> i32` => `{}`",
        std::any::type_name::<dyn Fn(i32, i32) -> i32>()
    );
    println!(
        "`dyn Foo<Bar = i32> + Send + Sync` => `{}`",
        std::any::type_name::<dyn Foo<Bar = i32> + Send + Sync>()
    );
}

`dyn Fn(i32, i32) -> i32` => `dyn core::ops::function::Fn<(i32, i32)>+Output = i32`
`dyn Foo<Bar = i32> + Send + Sync` => `dyn playground::Foo+Bar = i32+core::marker::Sync+core::marker::Send`

Just reuse pretty_print_dyn_existential which already makes an attempt to make its output stable.

[rustbot]

r? @eholk

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

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

[RalfJung]

This isn't really testing anything about const is it?

This doesn't even need a ui test, so library/core/tests/any.rs might be a better location.

[eholk]

Looks good to me, but I like @RalfJung's suggestion to move the test to a unit test, so I'll hold off on approving it to give you a chance to make that change.

Feel free to r=me once done.

[bors]

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

[rustbot]

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 @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. 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

[compiler-errors]

@bors r=eholk

[bors]

📌 Commit e24df27 has been approved by eholk

It is now in the queue for this repository.