rpi-pico: Multicore-safe atomics using hardware spinlocks.

[damaki]

This change implements an alternative implementation of the System.BB.Armv6m_Atomic package for use in the RP2040 which uses a hardware spinlock to ensure mutual exclusion for atomic operations between both cores. This is necessary since the default System.BB.Armv6m_Atomic package package is only safe for single processor configurations.

Additional GCC atomic built-in functions are also implemented using the same spinlock to ensure atomicity between all atomic operations. These are intended to be used by applications that make use of atomics, for example via the "atomic" crate in Alire.

A minor fix to the RP2040 alarm handler is also included to prevent the interrupt getting stuck set during startup, which in some cases has lead to infinite alarm interrupts.

Please note that I have been able to build and test these changes only with GNAT FSF 12 based on this branch: https://github.com/Fabien-Chouteau/bb-runtimes/tree/gnat-fsf-12 since I unfortunately do not have the toolchain/sources necessary to build the current master branch of this repository.

[Fabien-Chouteau]

Hi @damaki Thanks for the contribution.

I am ok with using spin-locks for the atomics, but I don't think the RP2040 run-time should implement all GCC atomic intrinsics. This would be better in an Alire crate and just keep the required functions in the run-time like we do for the other targets.

[damaki]

OK, I've removed the GCC __atomic intrinsics in commit ceed75b. I will create a separate Alire crate for the __atomic intrinsics.

I originally put them in the runtime to ensure atomicity between __sync and __atomic operations by using the same hardware spinlock (though new code should really be using __atomic instrinsics instead of __sync). Though thinking about it again, we can ensure the same atomicity by using the same hardware spinlock (SPINLOCK31) in both the crate and bb-runtimes.