allow concrete-eval for Union-type arguments

[aviatesk]

By allowing hasuniquerep to analyze Union-types. Motivated by aviatesk/JET.jl#444.

@vtjnash do you think this extension on hasuniquerep is valid?

[Keno]

I think this should be valid, because egal_types on union just defers to egal on the components and we always sort types on construction (and certainly anything that hasuniquerep has a well defined sort order under our predicate).

[vtjnash]

I don't think we don't always sort Union types on construction, and datatype_name_cmp gives up after a couple attempts at ordering as well. I think we need to make both of those stronger before we can assume they are always normalized.

[aviatesk]

I've exported union_sort_cmp and changed hasuniquerep to verify whether t.a/t.b of t::Union are sorted. This adjustment should allow for the correct use of hasuniquerep with Union, but does this seem like a correct?

[vtjnash]

I don't think union_sort_cmp is capable of meeting that sort of requirement. For example, it is easy to construct equal types for which the union_sort_cmp would necessarily choose different orders for the components:

julia> Union{Tuple{String}, Tuple{Real}}
Union{Tuple{Real}, Tuple{String}}

julia> Union{Tuple{String}, Tuple{R} where R<:Real}
Union{Tuple{String}, Tuple{R} where R<:Real}

julia> Union{Tuple{String}, Tuple{Real}} == Union{Tuple{String}, Tuple{R} where R<:Real}
true