`cortex_m::singleton` attribute forwarding is unsound in some cases

If you use link_section to put a singleton in an uninit section, the "has been taken" boolean is also in uninit memory at startup. We read this value which is uninitialized.

cortex-m/cortex-m/src/macros.rs

Lines 72 to 74 in f3f85e6

    
           $(#[$meta])* 
        
           static mut $name: (::core::mem::MaybeUninit<$ty>, bool) = 
        
               (::core::mem::MaybeUninit::uninit(), false);

We could potentially put the bool in a separate static that is in the "normal" .bss section, but we'd have to document this.

CC @jordens and #522

And it's especially bad for a bool being the prime example of not just uninit but even init with the wrong value causing UB.

(fwiw, "link_section" is always an easy way to cause unsoundness in safe code, as with basically any direction you give to the linker, but it FEELS like this is an unexpected outcome rather than an intended one, which we should probably fix and document, or at least document if we say "you can totally use this with link_section".)

Related: It looks like link_section is going to become officially unsafe. rust-lang/rust#129566

Of course, as using link_section is very useful and sometimes necessary in embedded contexts, we still should provide documentation on how to use it correctly.

What if the bool was split out to its own static which ignores the link_section things? Then the bool is guaranteed to be valid while the data part is free to be uninit in its wonky linker section

That was also my plan.

	$(#[$meta])*
	static mut $name: (::core::mem::MaybeUninit<$ty>, bool) =
	(::core::mem::MaybeUninit::uninit(), false);