Reseed Dice RNG on every Roll

[DavisNT]

This improves entropy of the Dice app, especially when triggered by shaking.
As a pleasant side effect this also makes the Dice app more like a physical dice - dependent on how it is shaken, but in an unpredictable (or at least not easy to predict) manner.
The monotonic counter xTaskGetTickCount() in the seed should greatly reduce chances of generating the same RNG seed in multiple rolls.

At least on my PineTime watch the motionController seems to return 12 bits for each axis and single axis very often gets saturated (returns 2047 or -2048) during shake, sometimes two axis get saturated during shake.
Assuming xTaskGetTickCount() resolution is close to 1 ms (and people have precision of no more than 64 - 256 ms), it should also provide at least around 6-8 bits of entropy its provided entropy likely will be limited by the temporal resolution of the mechanism triggering the roll (e.g. the accelerometer refresh rate of 10 Hz).
I think in most cases (unless the roller intentionally precisely times the roll and controls/predicts all 3 accelerometer axis), this PR should provide enough entropy to make a single number (in the 2-99 sides range) per roll truly-random. 🔒
And this PR should eliminate the biggest security problem with current Dice app implementation (regardless of whether std::mt19937 or std::minstd_rand is used) - ability to analyze results of certain number of Dice app rolls (likely little over 13 rolls of 6 sides in case of std::minstd_rand - assuming std::minstd_rand has 32-bit internal state and every roll leaks around 2.58 bits of it) and predict the results of all subsequent rolls (until the Dice app gets restarted).

TL;DR I think this could be a good addition to #2473 and a pretty cool thing on it's own as it makes the Dice app more like a real physical dice. 😎 🎲

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	385232B	0B
data	944B	0B
bss	22640B	0B

Run in InfiniEmu