Present the clipboard as an IO object

[oxinabox]

Idea as an alternative to #53199

I think InteractiveUtils could define a type Clipboard <: IO which accesses the clipboard.
Then could do things like

redirect_stdout(Clipboard()) do
    @code_llvm foo()
end

behind the scenes it would be using the clipboard functions we already have, and using IOBuffers.
I haven't fully thought it through, but I think it is all possible. We might need the user to provide file open strings like "r", "w", "a".

[vtjnash]

Or something like:

open(InteractiveUtils.clipboard) do io
    code_llvm(io, foo, ())
end

I think we would want to typically encourage doing this with local state, especially since there likely needs to be an explicit close(io) event that actually flushes everything to the clipboard.

[vtjnash]

Where the above code would de-sugar to:

sprint() do io
    code_llvm(io, foo, ())
end |> clipboard

[stevengj]

Why not just have a method

clipboard(f::Function) = clipboard(sprint(f))

so that you could do:

clipboard() do io
    # print stuff to io
end

? (Mildly "breaking", because the current form of clipboard(f::Function) will copy string(f) to the clipboard, but since this is nearly useless it's hard to imagine anyone doing it. Also, we are less strict about changing interactive interfaces.)

That seems a lot clearer to me — a Clipboard::IO device seems error-prone to me, since it's not obvious when it is "flushed" to the clipboard. When close is called? When you call flush? It would be tempting to use it without remembering to close it.