rand of AbstractArray

This undoes revert of #8309, and re-enables `rand` of long ranges, which was impossible after #8309 (hence the revert).
In this new PR, `rand(typemin(Int):typemax(Int))` remains valid, but there are new possibilities, like e.g. `rand(typemin(Int):1:typemax(Int))`.

It also seems that rand is now slightly faster in some cases (see for example small benchmark in #8563, i.e. `@time for i = 1:10000000; rand(1:4); end`).

The reason I didn't implement this in #8309 is that I don't think I'm the qualified person to introduce the needed functionalities, which is here provided by `cendof` and `cget`: these work like `endof` and `getindex` respectively but with 0-based index (like in C, hence the name; I found the name `cgetindex` too ugly as it has to be used in code, unlike `getindex` which has a nice sugar syntax).
The idea is that currently a range like `r=typemin(Int):typemax(Int)` is such that `r[endof(r)]` raises an `OverflowError`. So we need a (lower-level) way to request the element at any position of such ranges. With the new functions, `cget(r, 0) == typemin(Int)` and `cget(r, cendof(r)) == typemax(Int)` with `cendof(r) == typemax(Uint)`.
I expect this PR to be rejected but hope that in this case someone will implement alternative functions.

cc @ivarne (BTW, I removed the `T` type paramater, cf. your comment https://github.com/JuliaLang/julia/pull/8309#discussion_r17420965).
Thanks, but then I'm not sure what to do: rename this method to `cget_unsafe` instead? (in my mind, the "c" in "cget" was already a warning, and this is meant for internal use only). Or remove `@inbounds` and hope that there is no/little overhead?