`--trace-compile` prints incorrect (but well-formed) signatures for many `isbits` types

[topolarity]

When types contain isbits parameters, the runtime's built-in printing for these datatypes can end up printing a value whose type doesn't round-trip correctly, causing a (silently) incorrect pre-compile statement:

$ julia --trace-compile=stderr -q
julia> foo(::Type{T}) where T = rand(Bool)
foo (generic function with 1 method)

julia> foo(Tuple{1.0})
precompile(Tuple{typeof(Main.foo), Type{Tuple{1}}})

The problem is that jl_ isn't very careful about giving you a literal of the correct type:

julia> ccall(:jl_, Cvoid, (Any,), Tuple{1.0})
Tuple{1}
julia> ccall(:jl_, Cvoid, (Any,), Tuple{1})
Tuple{1}

This is another version of #28808, but I thought it was worth opening a separate issue since these are "valid" types but they are the wrong types (and we get it wrong for quite common values like Float64).

[Keno]

We should provide pretty printing for some of the builtin types - I think for everything else we just probably need to print raw byte values and have them be reinterpreted back.

[xal-0]

Here are a few more datatypes that don't round-trip properly.

Signed non-Int integer types:

julia> @ccall jl_(Int8(1)::Any)::Cvoid
1

julia> @ccall jl_(Int16(1)::Any)::Cvoid
1

julia> @ccall jl_(Int32(1)::Any)::Cvoid
1

Symbols with characters that are escaped differently from strings inside var:

julia> @ccall jl_(Symbol("\n")::Any)::Cvoid
:var"\n"

julia> Symbol("\n") === :var"\n"
false

[vtjnash]

Duplicate of #52677

[kpamnany]

Another one:

julia> @ccall jl_(Val{Inf}::Any)::Cvoid
Base.Val{inf}