Use single call to dsfmt_gv_genrand_uint32() for small ranges (Take 2)

[mschauer]

This fixes #5549 and is an extended version of #5578 to accommodate for future changes to Range1, see #5585

• This version constructs RandIntGen's from first() and last() instead of length() for Integer ranges, see first() and last() on empty ranges #2537
  * As known, tests in test/linalg.jl are sensitive to changes in the RNG and will break, see Saner error bounds on linear algebra tests #5605 Fixed by A more robust error bound for the determinant. #5902 !
• This fixes also Problem with rand(typemin(Int32):typemax(Int32)) #5550: internally in RandIntGen full ranges from typemin to typemax have nominal length zero last()-first()+1 == 0 and are handled correctly by using a variant of rem
• Using the full entropy: 2^31 fits two times into 2^32 and no samples get rejected
• I could add checks for empty Ranges if desired, currently rand(one(T):zero(T)) produces full range rand(T) ✅

This is tricky to test (e.g. it is not possible to check if rand(1:2^50) covers the full range or is exactly uniform...) so please have a close look for one-off-errors and ideas for good tests are welcome.

[mschauer]

@lindahua I am interested, what do you think? Speed diagram below.

Speed of rand(1:t, 10^6) for different values of t (dots) and of rand(uint32(1:t), 10^6) circles. The PR in red. Everything as expected, notably rand(0x00000001:0x80000000, 10^6) is faster than before (it fits twice into 2^32, but not into 2^32-1) and rand(0x0000000000000001:0x0000000080000001, 10^6) is slower than before and rand(typemin(Uint32):typemax(Uint32), 10^6) does not fail anymore.

[mschauer]

I just rebased this and thanks to recent improvements in the testing code for linear algebra (progress #5605) this passes now the tests.

[ViralBShah]

Could you rebase this one again?

[JeffBezanson]

Yes this would be nice to have.

[mschauer]

Ok, it is rebased on top of master.