method sort order assertion

[vtjnash]

The following set of definitions should be sorted by number, but do not get sorted correctly:

f(::Vector) = 1
f(::AbstractVector) = 2
f(::Matrix) = 3
f(::AbstractMatrix) = 4
f(::Array) = 5 # this ends up between 1 and 2 instead!

Assertion failed: (!jl_subtype((jl_value_t*)sig, (jl_value_t*)type)), function check_ambiguous_visitor, file /Volumes/Lion/Users/jameson/Documents/julia/src/gf.c, line 1129.

This breaks the DataArrays package (which tries to add this set of methods to the round function)

Specifically, the bug is that the following result is wrong:

julia> args_morespecific(Tuple{Array}, Tuple{AbstractVector})
true

Or that the following result is wrong:

julia> args_morespecific(Tuple{Matrix}, Tuple{AbstractVector})
false

since because Matrix <: Array, more-specific(Matrix) should be higher than more-specific(Array)

more generally, I believe this means that the formal definition of more-specific is exactly:
more-specific(A, B) implies more-specific(C, D) for-all C <: A and D >: B

[JeffBezanson]

Array should not be more specific than AbstractVector, since of course their intersection is Vector, but interestingly we've been getting this "wrong" since at least v0.3. Fixing it introduces ambiguities, so we'll have to carefully evaluate the impact.

[vtjnash]

From the travis log, it looks like all of the errors are of the form:
error calling f(Vector), f(Array) is ambiguous with f(AbstractVector)
And are getting triggered by one of the complicated type alias unions (perhaps AbstractVecOrMat?)

Which does seem to line up pretty closely with the assertion failure observed here.

[JeffBezanson]

Ah, looks like in <=0.5 we did have morespecific(Tuple{Matrix}, Tuple{AbstractVector}), so for now we should fix this that way instead. Then this won't be disruptive.