accept more Integer types for dims::Int... arguments

[stevengj]

As discussed on the mailing list, there's no real reason that functions like rand(dims::Int...) can't accept other Integer types. This patch genericizes a number of functions in Base that took Int... arguments to accept Integer....

There shouldn't be a performance penalty, since I made sure convert(Dims, dims::Dims) returns dims by adding a new diagonal tuple method to convert.

Functions accepting an explicit (Int...) (== Dims) tuple still require Int; it was too much of a pain to change these, and they are generally lower-level functions than the varargs functions.

[JeffBezanson]

There is somewhat of a reason, though I don't know how convincing: these signatures permit O(n^m) specializations. This can lead to excessive compilation and compile time. And at a certain point, julia will stop specializing, so you might get much worse performance for (Int64,Int64,Int64,Int32) than for (Int32,Int64). You are better off converting things to Int at the call site.

[quinnj]

#7709 was recently fixed that dealt with this same issue. I think it may be good to just allow Integer.... Ideally we'd be able to follow the pattern of allowing more general types at the UI/exported level, and take specific types for internals, but I'm not sure how relevant that with some of the definitions here.

[quinnj]

It seems we already have rand(dims::Integer...) at random.jl:209; are the other changes here still relevant/needed?

[stevengj]

There are also similar, reshape, getindex, and many other functions. But there doesn't seem to have been an recurring need for these, so maybe it's better to just close this for now and re-visit if the issue resurfaces.