Refactor IPC mechanism

An automated review flagged that the IPC crate (xous-ipc) has some problems with MemoryMessage.offset being untrusted and leading to panics and unchecked archive access.

This is a valid feedback, but I would say the more global issue is that the IPC mechanism in general needs to be re-considered. Part of the problem is that it's embedded extremely deeply in the Xous code base, so any changes to it are not easy to do. But, if I were to name a couple of features I'd love to see in a v2 if we're going to go through the trouble of refactoring this:

• Some way to handle bigger-than-one-page archives in a rational fashion. Right now, the approximation of "all messages are exactly one page in size" mostly works because most data structures fit this.Anything bigger than this has to be manually broken up and serialized across processes. It might be nice to have some zero-cost abstraction, if it exists, that could also handle large-than-one-page messages. This would simplify operations like files, network packets, and graphics where fairly large, nearly arbitrary-length objects may need to be shuttled across process boundaries.
• Some way to tie an rkyv type to the actual message being sent. At the moment, we simply have to trust whatever is arriving from a memory message to be the correct serialization of an rkyv object. I don't think this is an easy problem to solve, and maybe impossible to solve for arbitrary/maliciously crafted messages without adding an extreme amount of cryptographic overhead that would cause the system to grind to a halt in terms of performance. The intermediate solution might be an alternate API built into the IPC crate that can be invoked for e.g. high value services like the keystore, which does introduce the extreme measures for structure validation, and so developers can opt-in to a safer or at least hardened version of an inter-process IPC without having to re-invent the wheel every single time.