Use no_std-friendly spin::Mutex to avoid unsafe for static mut.

[anforowicz]

Description

When reviewing the crate when importing it into my project, I've noticed that some of the unsafe usage may be removed by using a Mutex<RefCell<...>>. Since crates/serde_anymap/src/lib.rs declares itself as #![no_std], we can't use std::sync::Mutex, but it seems that spin::Mutex is a no_std-friendly, relatively-widely-used alternative.

Things were okay before this PR, but removing unsafe still seems desirable:

• The create_register! macro had a safety comment explaining how "register call will always run at startup and never in parallel". After this PR maintainers and auditors don't have to think about it anymore (i.e. to reason how exactly the "always run at startup" guarantee is upheld).
• In manual registration mode, RegistryBuilder::register may have to be called manually, requiring the user of LibAFL to uphold the concurrency guarantees. After this PR the user of LibAFL still has to ensure that registration is done before serialization, but failure to synchronize can't cause undefined behavior (I.e. this PR removes one reason why users of LibAFL may have had to use unsafe blocks in the past).

Checklist

• I have run ./scripts/precommit.sh and addressed all comments
  • "Formatting python files" step failed saying "Bundled Python 3.8 not found". I think it is okay to ignore this, because this PR does not modify any Python files.

[domenukk]

So I think this PR makes sense in general, thanks!

The issue I see is that spinlocks introduce overhead. Since this locks on deserialize, finding a single new testcase will hit the registry of all nodes that will unpack this. This may add up? Especially if this introduces some sort of numa caching stuff, etc... I just don't know.

Since LibAFL runs single-threaded (multi-process) by design, for our use case this might be a net negative?

It would be interesting to either benchmark this, or simply add a safe variant for other crates that demand this.

Note that the deserializer (after the registry is done) should technically not need a full exclusive lock, but a RwLock, so that multiple threads (that we don't have, but anyway) can use it concurrently...

I'll leave this to smarter people like @addisoncrump