Emulate vsyscalls without patching

Currently we "support" vsyscalls by patching the vsyscall call site to do a regular syscall (via syscallbuf if possible). This only works when the call site matches the known patch template. In issue #2939 it seems that IFUNC tricks are used to make time@plt select the vsyscall as the implementation function, which means we can't safely recognize and patch the actual call site. In issue #2929 we seem to have a function making a direct vsyscall, but with code that doesn't match the template. For the latter case we probably can (and probably should) simply add a new template that matches that code. To handle the former case, we could emulate vsyscalls in rr, which is what this issue is about. (This would also fix #2929 but it would be unnecessarily slow during recording.)

There are three vsyscalls: gettimeofday, time, and getcpu. (See Linux arch/x86/entry/vsyscall/vsyscall_64.c.) Basically we would AutoRemoteSyscall the required syscall, write appropriate syscall entry/exit records to the trace (with the right recorded-memory records), and fix up tracee registers to match the results of executing the vsyscall (i.e. including the implied ret after the syscall).

One special case is if the tracee's seccomp policy disallows the syscall. Linux handles this case, but for us to handle it would be extra work, and tricky too. Probably we can just ignore it since no sane sandboxing policy would block any of those syscalls.

Read Linux arch/x86/entry/vsyscall/vsyscall_64.c to understand the three vsyscalls, then inspect rr's existing vsyscall call-site patching and AutoRemoteSyscall paths. Trace how syscall entry/exit and recorded-memory records are written and how tracee registers are fixed up. Done means all three vsyscalls can be emulated without patching, including the implied ret behavior and documented handling of seccomp restrictions.