Change the `memtest` module to `no_std`

[BrianShTsoi]

The memory test algorithms in the memtest module is mostly purely algorithmic. We can mark the module as no_std. This will be useful if we want to reuse the algorithms for memtesting in the exception handler.

[afranchuk]

Note that no_std can only be applied at a crate level. I'm checking now whether it's possible to do this.

[afranchuk]

It appears that this is mostly possible, however it would definitely require non-trivial work and API additions (for instance, in no_std the source of random would have to use SmallRng or OsRng).

Alternatively, the no_std version of the crate could expose all the easily no_std-compatible things (like the memtest module contents) and exclude the rest.

[marti4d]

Note that no_std can only be applied at a crate level. I'm checking now whether it's possible to do this.

I think Brian and I should've provided a bit more context here: We wrote memtest.rs in such a way that it should be fairly easy to spin it into its own crate. The thought was that memtest.rs would become a crate and the code in lib.rs that currently runs the memtests could be called something like memtest-runner.

The intent was that the memory tests themselves might be reusable in other projects, so we didn't want the memory testing code to be tightly coupled to the test-runner code; that way, the tests could be embedded into some other test-running framework, or called via FFI from other languages, or used in a pre-boot environment like MemTest86 is, or even possibly used in embedded systems without an OS if someone ever wanted to write a memory tester for an Arduino/PIC/ESP32/whatever.

This is why, for the most part, all the things in memtest.rs are (mostly) pure algorithms that don't use std or any other platform-integration... Or they're at-least close. I can see a couple things that we would need to change, though:

• We should probably consider using the getrandom crate instead of rand for the test that involves random number testing. getrandom allows embedded systems to provide their own platform integration.
• We currently import two things from std that can probably just be switched to core.

But otherwise, as long as we keep this separation, I don't think it should be too much effort to do this in the future 😁