Stop using r0 crate for user programs.

[cbiffle]

r0 is likely unsound. This replaces the data/bss init with an assembly
routine that is guaranteed not to get mangled by the compiler.

Context:
rust-lang/unsafe-code-guidelines#259

[cbiffle]

I've validated this most recent version on at least the STM32H7, so I reckon this is ready for review

[labbott]

In the existing r0 crate there's a compiler fence between init_data and zero_bss. I don't think we need to keep that since there should be no aliasing between data and bss so it should be fine to do a single call at the end.

[labbott]

https://github.com/rust-embedded/r0/blob/master/src/lib.rs meant to link this

[cbiffle]

Yeah, compiler_fence is only important when you're using a compiler -- it stops LLVM from moving loads and stores across that point, among other things. In our case, in assembly, there's no risk of our instructions getting moved.

Though your link reminded me that I did not implement r0's pre_init hook. I should make sure we're not relying on that anywhere.

[cbiffle]

Conclusion: we are totally relying on it, and so I have subtly broken initialization on the more complex chips...but in a way that passed the tests, interestingly. Hooray "manufacturer says this behavior is undefined!"

Will fix.

[cbiffle]

FALSE ALARM. This is for user programs. They don't use pre_init and have never actually had access to it. I was thinking of the kernel. Nevermind. :-)