Swap to just-stabilised asm!() and global_asm!() macros

[adamgreig]

Once Rust 1.59 is released in a couple of days, the asm!() and global_asm!() macros will become stable, and we will no longer require the various precompiled binaries we've used until now in cortex-m and cortex-m-rt. cc #420.

This PR uses asm!() in cortex-m, and removes the inline-asm feature, since I anticipate this going into cortex-m 0.8 and so we don't need to leave it behind for compatibility. In various places the previous version would call an extern C method when built for the native target, which would only fail at link time; to preserve the ability to build on x86 I've either made the whole method require the cortex_m configuration, or where appropriate/convenient simply skipped the asm!() call.

This PR replaces the old gcc-preprocessed asm.S in cortex-m-rt with use of global_asm!(), although since you can't normally use #[cfg(...)] attributes with global_asm!(), there's also a slightly scary macro modified from one invented by @Dirbaio for a similar purpose. I considered putting the initialisation of LR behind an armv6m flag, but since we want to restore it after calling __pre_init it seemed better to just leave it the same on both targets. I added Cargo features to optionally set SP and VTOR at startup, which has been variously requested but would previously have required multiplicatively more pre-built binaries. Now: no problem. Relevant issues:

• VTOR and initial stack for debuggers cortex-m-rt#283
• Support vector table relocation? cortex-m-rt#55
• Add force-setting of stack pointer in startup code cortex-m-rt#254
• DefaultPreInit gets random address in debug mode [Stack pointer initialization issue] cortex-m-rt#102
• Set SP and VTOR in Reset vector cortex-m-rt#338

I've tested these on a couple of targets (and updated the CI): on the whole there's a small improvement in code size due to everyone getting inlined asm, especially in cortex_m::interrupt::free().

The major downside is we bump our MSRV from 1.42 (March 2020) to 1.59 (Feb 2022). For cortex-m, I propose putting these changes in the upcoming 0.8 release (which is technically what the master branch is already on) and not backporting. For cortex-m-rt I'm not sure: we don't have any other pending breaking changes, so we could consider a patch release. Anyway, this PR doesn't commit to any particular releases, so we can decide that later.

For cortex-m-semihosting/panic-semihosting I think a patch release would be ideal, especially since we had to yank the last c-m-sh release due to conflicting prebuilt binaries (a problem that should now vanish).

Also tagging these issues that I think might also benefit from new inline asm:

• SWI / SVC support #265
• add virtual unwind info (.debug_frame / CFI) to external assembly #215
• Make the HardFault trampoline opt-in #406

[rust-highfive]

r? @thalesfragoso

(rust-highfive has picked a reviewer for you, use r? to override)

[thejpster]

I hope this clippy lint goes away in 1.59.

[thejpster]

Looks OK to me. Very excited to see this land!

[adamgreig]

I've fixed that uppercase BXNS, set rust-version in the Cargo.toml (except the unchanged panic-itm), bumped those Cargos to edition 2021 while we're at it, and removed outdated references to old Rust versions from cortex-m-rt docs (since we now require 1.59 anyway, and they were already outdated with 1.42).

[thejpster]

What happened to the CI?

[adamgreig]

Whew, a few snags from the CI but all green now.

[therealprof]

LGTM

[adamgreig]

bors r=thejpster

[bors]

Build succeeded:

• ci-linux (1.59.0)
• ci-linux (stable)
• clippy
• rt-ci-linux (1.59.0)
• rt-ci-linux (stable)
• rt-ci-other-os (macOS-latest)
• rt-ci-other-os (windows-latest)
• rustfmt