(more) precisely track memory accesses and allocations across FFI

[nia-e]

This greatly expands the information we have access to when code is executed across the FFI bound, including tracking exact allocations/deallocations (where possible) and accesses to Miri memory exposed to foreign code.

The current architecture forks Miri into 2 processes at the point of the first FFI call, with the parent ptraceing the child. Communication is done via IPC channels; the child process signals when to start or stop tracing (during FFI), and the parent returns information about memory accesses that occurred, if any.

Alternatives considered:

• FUSE: It would be possible to obtain most of the same information about accesses to our memory (but not allocations done on C's side) by registering a FUSE fs which lives entirely in memory and mmaping files from there to act as the machine's memory. The main benefits of this approach would be that it would be more portable as we'd no longer need to disassemble the foreign code to examine it (though we will still need to read arbitrary registers on the fly) and that it would give us slightly more accurate information about the sizes and types of memory accesses where the current approach lightly conservatively overestimates. However, I decided not to do this because it requires FUSE utils to actually be installed on the host system and would add a lot more complexity to the logic
• Plain sigactions: We can also get data by registering sigactions to trigger when foreign code accesses our memory, but even though this is much simpler it would only give us page-grained information about what was performed (where the current approach is more or less byte-grained)

As it stands, this PR is not ready for merging pending at least the following being resolved. Still, I am opening this because significant sections of the code are ready for (preliminary, this is still very WIP) review. In ~decreasing order of severity as I see it:

• Actually incorporate the obtained information into Miri's memory tracking instead of just printing to stderr
• General cleanup such as removing hardcoded unwraps, adding more documentation, etc
• Dynamically fall back to the old behaviour without panicking if the parent fails to trace properly, e.g. if ptrace is disabled
• Add more tests
• Add logic for non-x86 architectures
• Handle the foreign code spawning multiple threads

Open questions / fixable current limitations:

• Do we want to pull in an existing allocator instead of having our own for managing the machine memory?
• Can this be made to be combineable with a multi-seeded Miri run?
• What happens if the FFI code forks further (do we even allow it)?
• Should we switch out iced_x86 with something else (e.g. go ahead with the FUSE idea, or use Capstone/llvm-sys for the better compatibility and eat the binary size & compile time increase)?

Zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/269128-miri/topic/Initializing.20Miri.20memory.20from.20C.20FFI/with/518542321

Works toward (I hesitate to say closes) #11

[RalfJung]

Write-up of design options and choices: https://hackmd.io/@scZ140SZTaOb1VASX_ju-Q/SJUzIeo-eg

[nia-e]

This doesn't build or pass tests right now since it builds against my fork of rustc, but against it it passes all tests on x86 linux and (assuming I didn't mess them up) on other platforms as well!

[nia-e]

@rustbot ready

[RalfJung]

@rustbot author
based on discussion on Zulip re: splitting up the PR

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.