redirect_* doesn't work with have_color

[Roger-luo]

I'm not sure when exactly it stops working, consider the following code that redirects the colored printing to a Pipe buffer then read the String from it, I'm expecting to get the string with the corresponding ASCII color, but I only get the no-color printing.

old_stdout = stdout
stdout_buf = redirect_stdout()
stdout_reader = @async read(stdout_buf, String)
printstyled("aaa";color=:red,bold=true)
redirect_stdout(old_stdout)
close(stdout_buf)
print(fetch(stdout_reader))

I believe this is currently causing the color_output macro from Suppressor not working anymore (JuliaIO/Suppressor.jl#40, this is a separate issue due to the change of return value of redirect_stdout from Tuple{PipeEndpoint, PipeEndpoint} to PipeEndpoint). And it seems because the PipeEndpoint will return false for get(io, :color, false) inside with_output_color.

Currently the difference is for the default stdout, we have

julia/base/ttyhascolor.jl

Line 27 in f61eb87

get(::TTY, key::Symbol, default) = key === :color ? get_have_color() : default

but not for PipeEndpoint, I notice there has been discussion on this here #36671, thus I'm wondering what would be the best way to fix this? define a similar overload for PipeEndpoint seems not preferred since that could be a file? How do we allow users to turn on/off the color option when trying to dump the stdout to a string then?

[JeffBezanson]

The workaround would be to use redirect_stdout(IOContext(Pipe(), :color=>Base.get_have_color())).
We should possibly copy properties from the original stdout in redirect_stdout(), but I'm not sure...

related: #34721 #42649

[vtjnash]

I would say this is intentional, and not intended that we clone values from old stdout (which you can do explicitly, as you show). But perhaps we should apply --color=yes to the new stdout/stderr, if the user set that command line flag?