Rework trace storage

The current trace storage approach has some issues that we need to fix:

• Traces are written directly by the rr process and buffered data is not always flushed, so SIGKILL directed at the rr process (not uncommon, when rr is used as a wrapper around some program that normally is SIGKILLed by other code, e.g. on timeout) leaves an unusable trace.
• rr must finish writing a trace before anything can start consuming the trace. If we fixed this then you could start an rr replay concurrently with an rr record and be ready to debug as soon as an error is encountered instead of having to wait for the replay.
• There is no currently way to efficiently package a trace for copying or streaming to another machine for replay.
• Currently trace versioning is very primitive and there is no way for rr replay to consume trace versions other than the 'current' version.

On the other hand it has some important features we need to preserve:

• We avoid copying data by hardlinking and FICLONERANGEing files into the trace directory.
• Certain data records like memory-maps and trace-events are stored in their own files so tools can efficiently read those records without having to scan the whole trace.

No files, tests, or entry points are identified in the issue. Start by locating the trace-writing and replay paths, then compare their behavior with the requirements for crash resilience, concurrent consumption, packaging, and version compatibility. Done means a concrete storage design preserves hardlinking, FICLONERANGE, and efficient record access.