fix #30114, specificity transitivity errors in convert methods

[JeffBezanson]

After this, transitivity holds for all convert methods. Fortunately, this leaves all existing specificity and ambiguity tests passing, so this is potentially backportable if PkgEval agrees. Unfortunately, there are more transitivity failures in other functions (that I will soon address in another PR), and so far the fix for them seems to unavoidably change ambiguities.

Fixes #30114.

[JeffBezanson]

I think I can improve this a bit by picking over a piece of #30171.

[JeffBezanson]

Ok, the following test case works on master but fails on this branch:

let A = Tuple{Type{Interval{:closed,:closed,T} where T}, Interval{:closed,:closed,T} where T},
    B = Tuple{Type{II},                                  AbstractInterval} where II<:(Interval{:closed,:closed,T} where T),
    C = Tuple{Type{AbstractInterval},                    AbstractInterval}
    @test  args_morespecific(A, B)
    @test !args_morespecific(B, C)
    @test !args_morespecific(A, C)
end

I'll push an update that fixes it, at the cost of changing the result of 2 cases in the specificity tests. No new ambiguities though, so still pretty good.

[JeffBezanson]

Ok, I think I found a pretty good version of this where the only major change is that

(::Type{T})(x::T) where {T<:BitArray} = ...
BitArray(itr) = ...

is now ambiguous. That seems reasonable enough to me.