RFC: store strings in comparison test results instead of the original objects

[JeffBezanson]

This avoids deserialization errors; might fix #20230.

Motivated by a nasty one of these I got recently: https://ci.appveyor.com/project/JuliaLang/julia/build/1.0.21696/job/ernf3v0vhorc5w0f

[JeffBezanson]

Ok, unsurprisingly it takes a huge amount of time to stringify every test argument, so now this only stringifies when the test fails.

This also uncovered an obscure issue in show_default where forming a pair containing a shown value could fail if the value has bad convert methods.

[ssfrr]

This broke TestSetExtensions.jl, which relies on having access to the LHS and RHS of the comparison so it can display a pretty-printed diff on test failures.

Is it possible for this stringification to happen after the result is passed to the TestSet, so that custom TestSets can still have access to the values?

As a workaround I can eval the LHS and RHS of the original expression, but that's bad if they have side-effects.

[ssfrr]

hrm, eval isn't a great workround also because I'm evalling in the context of my code so it can't access any surrounding variables, e.g.

julia> x = [3, 4, 5];

julia> @testset ExtendedTestSet "testing" begin
           @test x == [1, 2, 3]
       end

I also don't understand the serialization problem that this PR was attempting to address well enough to have a sense for whether this could be easily reverted.

[iamed2]

Breaking TestSetExtensions in this way would be very unfortunate

[ssfrr]

Is there any chance this would be reverted? I'm thinking another option would be to just cut-paste Base.Test into TestSetExtensions rather than extending it, but that seems like a shame.

[ssfrr]

I talked to @JeffBezanson on slack about this. It seems like the thing to do is to move the stringification further down the chain, so they are still accessible to the testset, but get stringified before they make it to a different machine. I don't have time to get to it immediately, but hopefully within a couple weeks (if no one gets to it first...).

[ssfrr]

Oh, there was also some conversation about whether this would be a breaking change, but I'm pretty sure that accessing the data field of the result is considered mucking about with internals (AFAICT it's not documented anywhere), so it seemed like there was consensus that it's not considered breaking.