subtyping: fast path for lhs union and rhs typevar

[vtjnash]

Fixes #55230

[vtjnash]

@nanosoldier runbenchmarks(!"scalar", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[vtjnash]

Looking closer into a test failure, I realized this instead needed to be guarded with jl_has_free_typevars(u) (to avoid the possibility of a union element becoming degenerate in simple_join but not being able to detect that without testing each element separately). The remaining check e->Runions.depth == 0 is still needed to avoid introducing this failure:

Error in testset subtype:
Test Failed at /home/vtjnash/julia/test/subtype.jl:1642
  Expression: U2 == V
   Evaluated: Union{Tuple{LT, R, Int64} where {R<:Tuple{Int64}, LT<:Int64}, Tuple{LT, R, Int64} where {R<:Tuple{Int64}, LT<:R}} == Tuple{Union{Int64, Tuple{Int64}}, Tuple{Int64}, Int64}

Which comes from this kind of union-tuple switch:

julia> Tuple{Union{Int64, Tuple{Int64}}} <: Union{Tuple{<:Integer}, Tuple{<:Tuple}}
false # should be true

[vtjnash]

@nanosoldier runtests()

[nanosoldier]

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

[N5N3]

I haven't verified it locally, but this change seems to break Tuple{Union{Val{1},Val{2}}} <: Tuple{S} where {T, S<:Val{T}}?
(subtype_ccheck traverses all internal ∀ unions, so we need to ensure there's no free typevars in y's ub.)

[vtjnash]

You are correct, that one would be broken by this fast path attempt, so I added that as a test and added your suggested fix. Do you think this is correct now? Or would it still become wrong if something was added to the stenv constraints?