Document, Detect, Implement EFAULT handling in syscall handler

[Sonicadvance1]

Started in #3375
Continued in #3941

Our syscall handlers aren't always robust against EFAULT and in most cases we can't even detect it.

In #3375 we added memcpy handlers, which adds some overhead and programmer burden towards implementing the EFAULT handling without any guidance towards which syscalls are most likely to hit the problem.

In #3941 we added validation handlers which resolve if an argument has zero protections, read-only, or read-write capable. This allows us to sprinkle simple LOGMAN handlers around that add zero overhead in release mode, and doesn't place the burden on the programmer to actually implement the EFAULT handling at the start.

There is still a burden that we need to go through our non-passthrough syscall handlers and add these bound checks to the passed in user-pointers, but this is significantly lower effort. In addition to being lower effort, it will help inform our decisions about which syscalls need EFAULT handling on its arguments, since it'll give an assert message and can be tracked back to a failing syscall.

An additional task will be implementing an optimized inline memcpy for the handlers introduced in #3375. Currently these are quite slow, since they only copy byte-by-byte. If the memcpy handler is inline then we can detect a PC range for fault detection while still maintaining good speeds.