Use CHERI LLVM builtin names throughout CheriBSD, rather than our own cheric(3) API

[rwatson]

Although my fingers remember and therefore prefer our cheric(3) macros, it would make more sense to use the API documented in the CHERI C/C++ programming guide. We should shift over to using those, update man pages, etc. My preference would be to have our own definitions under _KERNEL in a system header so that they grep / etc well, even though third-party userlevel code will use the compiler-provided cheri.h.

[aestriplex]

Hello @rwatson, I'd like to start contributing to cheriBSD, and this seemed like a good place to start.
I could start replacing the man pages with something like this:

Legacy Function Signature	New Function Signature
ptraddr_t cheri_getaddress(void * __capability c)	vaddr_t cheri_address_get(void *c)
ptraddr_t cheri_getbase(void * __capability c)	vaddr_t cheri_base_get(void *c)
size_t cheri_getlen(void * __capability c)	size_t cheri_length_get(void *c)
size_t cheri_getoffset(void * __capability c)	size_t cheri_offset_get(void *c)
size_t cheri_getperm(void * __capability c)	size_t cheri_perms_get(void *c)
_Bool cheri_gettag(void * __capability c)	_Bool cheri_tag_get(void *c)
void * __capability cheri_setaddress(void * __capability c, ptraddr_t address)	void * cheri_address_set(void *c, vaddr_t a)
cheri_setbounds(c, length)	void * cheri_bounds_set(void *c, size_t x)

Apart from the man pages, which other areas of the documentation (or the code itself) could be most important for this replacement?

[brooksdavis]

In broad terms, I think we should focus on things that will land in the base RV64Y. A reasonable list can be found by looking at https://github.com/CHERI-Alliance/llvm-project/blob/codasip-cheri-riscv/clang/lib/Headers/cheriintrin.h. Beyond manpages we need to start switching userspace code from using sys/cheric.h to using cheriintrin.h. In the kernel we'll need to extend sys/cheric.h to also define the cheriintrin.h macro we need because some of the kernel is compiled such that it can't find the intrinsic headers.

A few more thoughts:

• most augments should be const
• s/vaddr_t/ptraddr_t/ everywhere. vaddr_t is obsolete and will be removed from the next release of CheriBSD where as ptraddr_t is (hopefully) on the way to standardization.
• One awkward bit is the builtins are actually polymorphic and take intptr_t (__intcap_t) as well as void *. I'm not sure how best to address that in the documentation. I guess you could list each prototype, but that might get ugly fast.
• I'm on the fence about including __capability qualifiers. It's accurate in CheriBSD, but we don't plan to upstream hybrid support to FreeBSD so it would be simpler if we didn't include them.