make collection constructors more uniform

[JeffBezanson]

fixes #4996 and #4871

change Set, IntSet, and PriorityQueue constructors to accept a single iterable

add an ObjectIdDict constructor accepting an iterable

now you can do this:

julia> pairs = [(1,2), (3,4)];

julia> ObjectIdDict(pairs)
{1=>2,3=>4}

julia> Dict(pairs)
[3=>4,1=>2]

julia> Collections.PriorityQueue(pairs)
[3=>4,1=>2]

julia> Set(pairs)
Set{(Int64,Int64)}([(1,2),(3,4)])

[JeffBezanson]

Come to think of it, it wouldn't be so bad to add a Collection type above AbstractArray, Associative, Set, String, etc. The main problems would be that (1) we can't capture everything that is iterable this way, (2) it's not clear whether some types (like String) really are primarily collections.

[kmsquire]

+1 for this PR.

I've pointed it out before, but I think the Scala collections hierarchy (or the immutable hierarchy) are well thought out and could provide a basis for collections in Julia.

In particular: Iterable and Sequence abstract types would be useful abstract types to have.

The lack of multiple inheritance in Julia does limit this somewhat (in Scala, these are traits, and classes can have multiple traits).

(This paper describes the meaning of Traversable, Iterable, and Seq in more detail, summarized here)

[stevengj]

It will be especially nice in conjunction with #4470, as this will give us comprehension-like syntax for all these collections.

[StefanKarpinski]

Yes, very true. That will be a very nice interface.