Allow other int types for type container size

[KronosTheLate]

This PR aims to solve #891, and check if this issue occurs for other types as well. For the types listed in the documentation, the results are seen in the drop-down below.

Details

Deque (implemented with an unrolled linked list) errors on `Deque{Float64}(Int32(10))`. Fixed

CircularBuffer
Silent error on CircularBuffer{Float32}(Int32(10)). Fixed

CircularDeque (based on a circular buffer)
errors on CircularDeque{Float32}(Int32(10)). Fixed

Stack
errors on Stack{Float64}(Int32(5)). Got fixed, I think with Deque

Queue
errors on Queue{Float64}(Int32(5)). Got fixed, I think with Deque

Priority Queue
No length parameter upon initialization

Fenwick Tree
Works for FenwickTree{Float64}(Int32(5)) and FenwickTree{Float64}(Int16(5))

No length parameter upon initialization for the following types
Accumulators and Counters (i.e. Multisets / Bags)
Disjoint Sets
Binary Heap
Mutable Binary Heap
Ordered Dicts and Sets
RobinDict and OrderedRobinDict (implemented with Robin Hood Hashing)
SwissDict (inspired from SwissTables)
Dictionaries with Defaults
Trie
Linked List and Mutable Linked List
Sorted Dict, Sorted Multi-Dict and Sorted Set
DataStructures.IntSet
SparseIntSet
DiBitVector
Red Black Tree
AVL Tree
Splay Tree

[oxinabox]

I think we can just do

Suggested change

	CircularDeque{T}(n::Int) where {T} = CircularDeque(Vector{T}(undef, n), n, 0, 1, n)
	CircularDeque{T}(n::Integer) where {T} = CircularDeque(Vector{T}(undef, Int(n)), Int(n), 0, 1, Int(n))
	CircularDeque{T}(n::Integer) where {T} = CircularDeque(Vector{T}(undef, n), n, 0, 1, n)

since constructors automatically call convert on all arguments.

[KronosTheLate]

I though about that option, but it somehow seemed more clear to me to explicitly do what will happen automatically. It somehow makes the code more readable to me, because it shows it's purpose more clearly. But I do not have strong opinions, so if you prefer this, it is fine by me ^_^

[oxinabox]

I see your point (getting rid of this behavour has actually been talked about for julia 2.0).

On the other hand, code that doesn't exist can't have bugs.

[oxinabox]

Per above i don't think this is needed since constructors automatically convert.
Even if you have another inner constructor.

Suggested change

	# Convert any `Integer` to whatever `Int` is on the relevant machine
	CircularBuffer{T}(f::Integer, len::Integer, buf::Integer) where {T} = CircularBuffer{T}(Int(f), Int(len), Int(buf))

[oxinabox]

Per above

Suggested change

	# Convert any `Integer` to whatever `Int` is on the relevant machine
	DequeBlock{T}(capa::Integer, front::Integer) where T = DequeBlock{T}(Int(capa), Int(front))

[KronosTheLate]

Regarding your reviews, I though you were mainly changing my ecplixit conversion via Int(arg). But I had to add the lines in the first place to make it work. Have you tested your suggestions?

[oxinabox]

Have you tested your suggestions?

I have not.
If you say they proved nesc then I will go with that.
As my opinon is not strong

[oxinabox]

Do you need this backported to 0.18?

[timholy]

Fun fact: sometimes it's useful to use the Foo(n::Integer, args...) = Foo(Int(n), args...) pattern even for constructors that perform automatic conversion. The reason? It confines specialization-diversity to a short "stub" function, and the "long function" (the one that does the actual work) gets compiled for a narrow range of types. I.e., less latency.

That said, here the constructors are short so I don't think it's a big deal either way.

[KronosTheLate]

Do you need this backported to 0.18?

If you are asking me, then no ^_^