support P packet

[froydnj]

Being able to write registers is useful.

I don't know how we'd pass the data along to the handler, since the P packet parses the new value in target byte order. I guess we could just start assuming little-endian and punt on endianness specifications until we actually need it? Then again, we may not want to parse the data into u32 or u64 (e.g. for SIMD registers)...but requiring all Handler implementations to read out integers from a Vec<u8> doesn't sound super-friendly.

[tromey]

We could wrap the data in some structure that provides methods like as_u64, but also allows access to the raw bytes for wider registers.

[luser]

I only had fuzzy ideas around target architectures, but I was figuring we could probably have some trait that defined an architecture, and build-in a few of the most common ones (x86, x86-64, arm, aarch64, at least) so that users on common architectures wouldn't have to do much work there, and then that trait could define the endianness. I was hoping we could bake-in the XML target definitions from GDB as well (rr seems to do this). If someone wants to use a weirdo target they could just implement the trait and things should be OK.

[tromey]

The M packet patch includes a parser for a sequence of hex-encoded bytes. That would be useful here.