ambiguity detection: more optimal code order

[vtjnash]

This can dramatically improve the computational effort for queries with a lot of resolved ambiguities (and will change the result of these). Those can occasionally happen for cases where Type{Union{}} is a part of the result, but where this is also an explicit method defined, such as this eltype query:

julia> @time Base._methods_by_ftype(Tuple{typeof(eltype), Type{A} where A<:(NamedTuple{names, T} where T<:Tuple where names)}, -1, Base.get_world_counter())
# master
  0.009458 seconds (12.56 k allocations: 414.719 KiB) # 25 results, scales badly with number of packages loaded
# PR
  0.001323 seconds (1.97 k allocations: 82.312 KiB) # 2 results, unaffected by number of packages loaded

[vtjnash]

@nanosoldier runtests()

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected.
A full report can be found here.

[vtjnash]

Some interesting failures there to look into, but nothing that seems related