nrest=n+4 in mersenne_twister

[NickSzapiro-NOAA]

This fixes the compiler warning:

mersenne_twister.F90:256:38:
            get(n+3:nrest)=transfer(stat%gset,get,nrest-(n+3)+1)
Warning: Intrinsic TRANSFER has partly undefined result: source size 8 < result size 16 [-Wsurprising]

and was bit-for-bit in ufs-weather-model regression tests a couple weeks ago.

The solution is by @DusanJovic-NOAA, with this context:

gset is declared as :
$ grep ':: gset' stochastic_physics/mersenne_twister.F90 FV3/ccpp/physics/physics/Radiation/mersenne_twister.f
stochastic_physics/mersenne_twister.F90:          real(kind_dbl_prec):: gset
FV3/ccpp/physics/physics/Radiation/mersenne_twister.f:          real(kind_dbl_prec):: gset
kind_dbl_prec is 8 bytes (64-bits) so get array (integer) should also be 64-bits or 2 element 32-bits array, 
to match the bitwise length of the gset. 

So to be 2-element array, the
get(n+3:nrest) =nrest 
must be n+4, and it is now defined as:
integer,parameter:: nrest=n+6

The caveat is that we are not familiar with this code, so we're hoping somebody who really understand what's going on here should double check this

The need is that, currently, ufs-weather-model RTs show a pattern of a "ball of diffs" in cpld_debug_gefs_intel (and cpld_debug_gefsv13_intel), failing in run-to-run reproducibility (ufs-community/ufs-weather-model#2675).

Changing this in both stochastic physics and ccpp improves reproducibility in these tests as well.

[pjpegion]

I am not familiar with the random number generator code either, so I cannot tell you why it was coded like this. I assume this will change the baselines

[NickSzapiro-NOAA]

Thanks @pjpegion . It was bit-for-bit for RTs in rt.conf when I tested.

It does impact run-to-run reproducibility in GEFS debug mode, which isn't run by default. Presumably intel non-debug is setting these undefined bits somehow

[pjpegion]

Change look good.