Introduce back atomic & support

[kammce]

We need to figure out how we want to handle cortex-m0 and the like which do not have atomics. My first choice is to provide a polyfill and fall back to int or potentially volatile int.

[kammce]

Claude gave me an interesting idea that I think I might pursue. Basically, add an option to the library to enable thread_safety. We can have a policy based on the ref_info type. We can have an atomic and non-atomic version. The only issue with this would be needing to build libraries against both for ABI concerns.

[kammce]

Actually the ABI issues would be a deal breaker. So no, we'd just need a fallback.

[kammce]

Following up on this, what we can do today is simply have a polyfill for this for systems that do not support atomics, like cortex m0, m0+ and m1. That polyfill type will fallback to a integer and would be considered thread unsafe to use. Later we can add support for thread safety by disabling interrupts for cortex-m0,m0+ and m1.

[kammce]

Also, we do not currently build our binaries for m0, m0+ or m1, due to issues with C++20 coroutines, so it may be possible to bring back support for now until we can expand support later.