Bogus "get_memory_info mismatch" warnings

As pointed out in #2539, there have been a lot of instances of this warning:

https://github.com/DynamoRIO/dynamorio/issues?utf8=%E2%9C%93&q=is%3Aissue%20%22get_memory_info%20mismatch%22%20

Here is a simple program that seems to generate the warning on X86_64 and on AArch64:
```
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include

void maps(void)
{
char buf[10000];
int fd = open("/proc/self/maps", O_RDONLY);
ssize_t n = read(fd, buf, sizeof(buf));
printf("--------\n");
fflush(stdout);
if (n > 0)
write(1, buf, n);
}

int main()
{
int page = getpagesize();
char *p = (void *)syscall(SYS_mmap, 0, page * 5, PROT_NONE,
MAP_PRIVATE | MAP_ANONYMOUS,
-1, 0);
printf("%p\n", p);
printf("%p\n", (void *)syscall(SYS_mmap, p + page * 2, page * 2,
PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED,
-1, 0));
printf("%d\n", (int)syscall(SYS_mprotect, p + page * 2, page, PROT_NONE));
maps();
printf("%p\n", (void *)syscall(SYS_mmap, p + page, page,
PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED,
-1, 0));
maps();
return 0;
}
```

Extract from output on AArch64:
```
0x7f7c862000
0x7f7c864000
0
...
7f7c862000-7f7c864000 ---p 00000000 00:00 0 <---
7f7c864000-7f7c865000 ---p 00000000 00:00 0 <---
7f7c865000-7f7c866000 rw-p 00000000 00:00 0
7f7c866000-7f7c867000 ---p 00000000 00:00 0
...

...
7f7c862000-7f7c863000 ---p 00000000 00:00 0
7f7c863000-7f7c864000 rw-p 00000000 00:00 0
7f7c864000-7f7c865000 ---p 00000000 00:00 0
7f7c865000-7f7c866000 rw-p 00000000 00:00 0
7f7c866000-7f7c867000 ---p 00000000 00:00 0
```

It looks as though DynamoRIO gets confused by the adjacent regions with the same permissions, indicated above by `<---`. So the warning is wrong: it should say `can happen if os does not combine entries`!

DynamoRIO should cope with the kernel either combining or not combining the entries and not generate bogus warnings that give an impression of general flakiness when in fact nothing particularly unusual has happened. Then we might be able to detect when something actually interesting happens.

(How I obtained this program: I took the example from #2506 and ran it under strace, which revealed the sequence of system calls that led to the warning in that case. The same could be done with other examples. In the example from #2506 the second call to `mmap` also used `MAP_STACK` but I removed it because it did not seem to make any difference.)