random: Optimize data flow for the generate function of native engines

[TimWolla]

Instead of returning the generated uint64_t and providing the size (i.e. the number of bytes of the generated value) out-of-band via the last_generated_size member of the php_random_status struct, the generate function is now expected to return a new php_random_result struct containing both the size and the result.

This has two benefits, one for the developer:

It's no longer possible to forget setting last_generated_size to the correct value, because it now happens at the time of returning from the function.

and the other benefit is for performance:

The php_random_result struct will be returned as a register pair, thus the size will be directly available without reloading it from main memory.

Checking a simplified version of php_random_range64() on Compiler Explorer (“Godbolt”) with clang 17 shows a single change in the resulting assembly showcasing the improvement (https://godbolt.org/z/G4WjdYxqx):

- add     rbp, qword ptr [r14]
+ add     rbp, rdx

Empirical testing confirms a measurable performance increase for the Randomizer::getBytes() method:

<?php
$e = new Random\Engine\Xoshiro256StarStar(0);
$r = new Random\Randomizer($e);

var_dump(strlen($r->getBytes(100000000)));

goes from 250ms (before the change) to 220ms (after the change). While generating 100 MB of random data certainly is not the most common use case, it confirms the theoretical improvement in practice.

[Girgias]

This makes sense to me, but will let other people have a look too

[zeriyoshi]

Sorry for the delay in checking, but I think it is good!
I will check it in detail tomorrow.

[zeriyoshi]

Looks great! Thank you!

[iluuu1994]

LGTM as well.

[iluuu1994]

Nit: The order of all initializers is inversed, so maybe inverse it here too?

[TimWolla]

I've initially had it reversed, but this order minimizes the differences in the generated assembly, because .result stays in rax (with .size being in rdx, instead of vice versa).