oofatfs: enable use of random volume IDs

[jepler]

This is a speculative fix for #7409 if the underlying cause is the deterministic volume ID. However, not all boards have working urandom (samd21 at least does not) so a couple of fallbacks are attempted when it fails. Note that the final fallback to the monotonic time is not great but probably has at least a few bits of randomness in it so it's better than nothing.

I verified that on a pico_w, each storage.erase_filesystem() gives a distinct 32-bit volume ID (pico_w's urandom can never fail)

Note that this doesn't change the unique ID of an existing CIRCUITPY, only when storage.erase_filesystem() is called or when the drive is first initialized on a fresh device.

[dhalbert]

Another fairly changeable number I looked at (by experiment) is microcontroller.cpu.temperature, if available, and microcontroller.cpu.voltage (if actually measured). The degree of precision on these varies: on SAMD21, temperature has only a few digits, but voltage has more. On RP2040, temperature has more, but there is no dynamic voltage measurement. However, both of these have a true UID so the point for them is moot.

[anecdata]

storage.erase_filesystem() with unique volume_uuid fixes #7409. 🎉 Thanks @jepler!!

[Neradoc]

This also fixes the long standing elusive issue with the Finder opening a file from the wrong board even before Ventura. (I tested it with nuking 2 picos and could see that the volume_uuid was the same before the PR and different after).
I wrote a few notes on that bug, but it seems that there isn't an open issue.

[tannewt]

Nice find! This makes total sense to me!