Bug 505673 - Valgrind crashes with an internal error and SIGBUS when the guest tries...

Bug 505673 - Valgrind crashes with an internal error and SIGBUS when the guest tries to open its own file with O_WRONLY|O_CREAT|O_TRUNC

This is all quite messy.

It affects open() openat() and openat2() (the last of which is Linux only).
On Linux we also need to check for /proc/self/exe and /proc/PID/exe.
On Linux there are also a couple of RESOLVE flags for openat2() that
mean _don't_ check /proc magic links.
In the general case we need to have some reference to check whether
the filename matches the guest filename. So I've added that as
VG_(resolved_exename) (which I was already using on FreeBSD).
The pathname also needs to be canonicalised. It may be a
relative path, symlink or use RESOLVE_IN_ROOT. That uses
VG_(realpath) (again which was already present for FreBSD).
On illumos the man page says that opening running binaries for
writing failes with errno set to ETXTBSY but that's not what
the open functions do - they just open the file. So I've done nothing
for illumos or Solaris. Maybe I'll open an illumos ticket.
I haven't tried on Darwin.

The Linux open functions with /proc/self/exe and /proc/PID/exe
were just calling dup on the fd that we hold for the client exe.
That means that we were ignoring any other flags. That has now changed.
If the open doesn't fail because the WRONLY/RDWR flags are set then
the syscall gets called from the PRE wrapper using VG_(resolved_exename)
instewad of the /proc pathname.

I haven't tried to handle all of the Linux openat2 RESOLVE*
flags. RESOLVE_NO_MAGICLINKS is handled and I see the LTS test
openat202 now passing, so this should also fix Bug 506910.

I'm not sure that VG_(realpath) handles all forms of weird path
resolution on Linux (on FreeBSD it uses a syscall so that should
work OK).