Support loading symbols for shared libraries from the trace

Currently gdb tries to load symbols for shared libraries by grabbing the file names from tracee memory and trying to read those files in the local filesystem. That won't work well when the local files have changed or are simply not there. In those cases gdb needs to read symbols from files in our trace.

In 6b272d5a27a73c071ed492db0e4a2ccfcb04536f we added support for vFile in the remote protocol, and gdb would normally use this to load files from the remote target, but we disabled that by forcing set sysroot /. If we remove that command then gdb will request files from rr, so in principle we could return the contents of files from our trace, but there are a couple of problems:

• Shoveling large files through the remote protocol socket is slow. I don't think there's much we can do about this without modifying gdb.
• The filenames in tracee memory (and thus supplied by gdb) often refer to symbolic links to the real files. The "original file names" in the rr trace are obtained from /proc/.../maps, which gives the real names. Thus, identifying the correct trace file for the name provided by gdb is difficult.

Start with rr’s vFile handling and the code that disables remote file access via set sysroot /; compare filenames from tracee memory with the original names recorded by /proc/.../maps. Define a way for GDB to obtain shared-library symbols from the trace, including symbolic-link resolution, and verify loading works without relying on changed local files.