Make armv6m-atomic-hack less annoying

[hawkw]

Currently, the armv6m-atomic-hack crate is, to use a technical term,
annoying. Its extension traits only exist when #[cfg(armv6m)] is
set. This means that, in downstream crates that wish to use
armv6m-atomic-hack to support v6m targets, the extension traits may
only be imported when #[cfg(armv6m)] is set. Because RUSTFLAGS cfgs
don't propagate across dependency boundaries, this means that each
dependent of armv6m-atomic-hack must add a build script with a call to
build_utils::expose_m_profile() so that the cfg is set properly when
building for a v6m board. This is, as previously stated, annoying ---
especially when using crates like counters, whose #[derive(Count)]
attribute expands to a use of AtomicU32Ext, and thus requires any
crate that derives Count to add a build script.

This branch changes armv6m-atomic-hack so that the extension traits
AtomicU32Ext and AtomicBoolExt are always defined, regardless of
whether #[cfg(armv6m)] is set. Now, only the implementation of those
traits differs based on the presence of the armv6m cfg --- if it is
not set, an implementation is provided that simply forwards to the
corresponding methods on the AtomicU32 and AtomicBool types in
libcore. This way, dependents of armv6m-atomic-hack can just import
the extension traits without needing to add a build script with
expose_m_profile(); now, only armv6m-atomic-hack itself needs the
build script. Now, the armv6m-atomic-hack crate can no longer be
considered annoying.

[cbiffle]

Nice!