add Random.jump(rng) API
We have long had methods for RNG "jumps ahead", i.e. advancing the state by
a given number of "steps", but no good API for that.
The only public API is `Future.randjump(r::MersenneTwister, steps::Integer)`,
and there are also functions for `Xoshiro` which are not public
(`Random.jump_128` and friends).
The following generic API is implemented here:
* `Random.jump(rng)` to jump by a reasonable default number of steps
* `Random.jump(rng; by::Real)` to jump by `by` steps
* `Random.jump!(rng; [by])` to equivalently jump in-place
* `Random.jump(rng, dims...; [by])` to create an array of jumped RNGs
In old julia versions, there also existed a method of `randjump` returning an
array, but the 1st element of this array was the passed argument;
the version here does not do this aliasing.
There are two kinds of integers one would wish to pass: dimensions for the array
version, and the number of steps.
Using jumps is relatively "niche", but needing to fidle with the number of steps
is even more niche. It's expected that in the vast majority of cases,
a good default is enough.
Some APIs in other languages have `jump` (e.g. 2^128 steps) and `long_jump`
(e.g. 2^192 steps), or `leap` in java, for more complicated cases;
for example each process gets a jumped RNG via
`long_jump`, and within each process, each thread gets a jumped RNG via `jump`.
But this is not very scalable if more kind of jumps are needed: should
`huge_jump` be introduced? For these rare cases where the default number of
steps is not sufficient, it seems better to let the programmer explicitly
specify the number of steps via an integer.
There is even a third kind of integers one might want to pass: in
`Random.jump_128(x::Xoshiro, i::Integer)`, `i` represents the number of times
a jump of size `2^128` is applied; this is because `Xoshiro` doesn't support
arbitrary number of steps; this is not supported in the proposed API, because
1) it's trivial for the user to implement herself, and 2) in probably most use
cases, using the array version will be a valid alternative, and more efficient
because previous computations are not wasted
(like in `[Random.jump_128(x, i) for i=1:num_tasks]` vs
`Random.jump(x, num_tasks)`).
Another argument in favor of this API is that it mirrors the
proposed `Random.fork(rng, dims...)` function from #58193.
