Add _c forms of atomic functions

Add _c forms of atomic functions

This patch adds atomic functions that take __capability pointers
as arguments.  Following clang's example (and the convention
for memcpy, etc.), these functions are distinguished from
non-__capability versions by having a “_c” suffix.

The two obvious options were:

(1) Put these _c functions in a group after the non-_c functions.
(2) Put each _c function after the corresponding non-_c function.

The patch goes for (2), since it makes it easier to handle
the difference between functions that have intcap forms
and functions that don't.

The vast majority of backend atomics patterns can only handle
the non-_c form, so the generic aarch64_sync_memory_operand
requires normal-base addresses.  However, we can support
alternative-base forms of some atomic loads and stores.

The atomic_load and atomic_store expanders filter out which
forms of load and store can handle alternative base addresses
and FAIL those that can't.  Target-independent code then uses
fallback paths for those cases.

Doing this exposed a couple of bugs in the fallback paths
of expand_compare_and_swap_loop (which didn't clean up
after a failed sequence) and expand_atomic_fetch_op
(which was missing a null check).

The existing behaviour of __ATOMIC_CONSUME is different from
(more relaxed than) __ATOMIC_ACQUIRE, which is inconsistent
with the documentation:

@item __ATOMIC_CONSUME
This is currently implemented using the stronger @code{__ATOMIC_ACQUIRE}
memory order because of a deficiency in C++11's semantics for
@code{memory_order_consume}.

But that isn't really relevant to this patch.  All that matters
is that the tests are in sync.

The atomic_load insn checks for is_mm_release (model) and
the atomic_store insn checks for is_mm_acquire (model),
but those conditions would never be triggered by valid uses of
the associated __atomic_load_* and __atomic_store_* functions.