Basic multi-threaded capability tag implementation

[LawrenceEsswood]

When MTTCG is enabled, this turns every tag bit into a write-preferring readers-writer lock. When single-threaded, the old one bit per tag is used.

Originally this was based on the morello branch, and so although I have tried to keep it separate, some general fixes I did there have crept in. Namely, the raw_tag version of capability loading (to get the un-squashed tag to implement atomics), and some sign fixes for TCG atomics.

[LawrenceEsswood]

This may want a little more testing, but purecap riscv boots.

[arichardson]

I am seeing the following error booting a purecap kernel (looks like my initial atomics implementation is broken for multi-tcg):

/local/scratch/alr48/cheri/output/sdk/bin/qemu-system-riscv64cheri.with-multi-tcg -M virt -m 2048 -nographic -bios bbl-riscv64cheri-virt-fw_jump.bin -kernel /local/scratch/alr48/cheri/output/kernel-riscv64-purecap.CHERI-PURECAP-QEMU-MFS-ROOT -append init_path=/sbin/startup-benchmark.sh
bbl loader
qemu-system-riscv64cheri.with-multi-tcg: ../../qemu/target/riscv/op_helper_cheri.c:313: void lr_c_impl(CPUArchState *, uint32_t, uint32_t, target_long, uintptr_t): Assertion `!qemu_tcg_mttcg_enabled() || (cpu_in_exclusive_context(env_cpu(env)) && "Should have raised EXCP_ATOMIC")' failed.
Aborted (core dumped)

[jrtc27]

Probably better to not permit NULL here and force callers to do the right thing. I think most do already, just store_cap_to_memory that doesn't check take_lock?

[LawrenceEsswood]

I wanted to distinguish between there being no locking due to being single core (NULL) and there being locking but no lock at this location (TAG_LOCK_NONE). The lock_for_x family will all return NULL if locking is off, which will then be ignored by release.