umbra mapping fails when vdso is placed in 0x7fff'ff4-0x7fff'ff8 gap

Just running in a loop after fixing #1712 I still see a failure. This time though it's due to the kernel placing the stack, vvar, and vdso in the 0x7fff'ff4-0x7fff'ff8 gap which umbra assumes has nothing in it:

```
adding app segment [0x00007f00'00000000, 0x00008000'00000000)
ERROR: new app segment [0x00007f00'00000000, 0x00007fff'ff400000) conflicts with app seg [0x00007f00'00000000, 0x00008000'00000000)
ERROR: shadow segment failed for 0x00007f00'00000000-0x00007fff'ff400000
ASSERT FAILURE (thread 2826784): /home/bruening/drmemory/git/src/drmemory/shadow.c:289: false (fail to create shadow memory mapping)
```

```
$ cat /proc/`pgrep mmap`/maps
7ff8'6fe2d000-7ff86fe6d000 rw-p 00000000 00:00 0
<...>
7ffa'84267000-7ffa8429f000 rw-p 00000000 00:00 0
7fff'ff786000-7fffff7a7000 rw-p 00000000 00:00 0 [stack]
7fff'ff7ae000-7fffff7b2000 r--p 00000000 00:00 0 [vvar]
7fff'ff7b2000-7fffff7b4000 r-xp 00000000 00:00 0 [vdso]
```

And here #1798 won't help b/c the kernel allocated there and it's too late for umbra to do anything about it.

@johnfxgalea -- this assumption is seeming untenable, unless we require running with ASLR disabled or sthg extreme, or we set the libdynamorio.so base to cover this gap, or other crazy things that would all rule out attach to an existing process launched some other way.

If we do accept that the kernel might put something there: the new tool from PR #2300 showed there is no mapping solution, right? What were we considering before: not allowing vsyscall to be shadowed?