Make srand work similarly for global RNG and MersenneTwister instance

[rfourquet]

The docs pretended it did, but were lying.
Also, the first commit simplifies (see commit message) MersenneTwister in order to homogeneize how its constructor and its srand method work (the constructor now calls srand).

I would like to add another change (which is more breaking), but need feed-back: MersenneTwister() returns always a "similiar" instance by calling MersenneTwister(0) (I find this surprising), whereas srand(r::MersenneTwister) seeds r with the help of OS' provided entropy. This is not consistent and I'd prefer the second behavior for both methods (i.e. MersenneTwister() = (m = MersenneTwister(0); srand(m); m) or equivalent).
In fact I would like MersenneTwister having a unique constructor with unconstrained parameter which calls srand (boils down to adding string to the possible parameter types).

[rfourquet]

I had also one question: is there a particular reason why using the global RNG controlled by SFMT is preferred over handling a global MersenneTwister insance on the Julia side?

[andreasnoack]

For the last question, I think it is faster to use the global RNG controlled by DSFMT.

Wouldn't it make sense to feed the seed to the MersenneTwister constructor instead of having an srand method for RNGs?

[rfourquet]

@andreasnoack Thanks for your answer, I'll probably test the speed difference someday.
I think your proposition can make sense, but then it would not be possible to reseed an existing instance, which I don't find too limiting (however I just checked a 3kB state array per instance, so why not reusing the same instance when one wants to re-seed?).

[ViralBShah]

We should definitely test the performance.

[rfourquet]

I forgot one good reason to keep srand in addition to constructor: when other RNGs are implemented, srand(r,seed) is better for generic code than r=MersenneTwister(seed).

[andreasnoack]

@rfourquet That might be right, but different RGNs might have different seeding types, but let's postpone that discussion to the time when we have more RNGs.

[ivarne]

In future API discussions, we must also consider thread safety. Can srand() with a known seed for reproducibility really work in a multi threaded environment?

[rfourquet]

I think srand(seed) in a multithreaded environment should be very rarely used, and that srand has to handle a lock itself, unless the "global" rng becomes thread-local. Multi-threaded programs should probably use non-global rng instances.

[rfourquet]

Closing since this PR is superseded by #8380 which extends this work to the rand[!] functions.