Try to allocate executable memory close to PPSSPP memory if not below 4GB

This tries to work around #1106 without having to remove RIP-relative addressing from the X64 emitter.

Both Windows and *nix follow a similar strategy: find the location of PPSSPP global variables in memory and try to find free memory areas below it. We don't search up because we could be at the upper-limit on usable memory in the process. On Windows we specifically query each memory region until we find one that is free. On *nix, we jump down 0.5GB in virtual memory and try allocating there, relying on the fact that mmap can search around if it can't use the exact address passed in. These new routines only happen if PPSSPP is in high memory (>0xFFFFFFFF) and if it's in low memory it falls back to the existing behavior for that.
It's no longer static so presumably this case isn't possible?

In that case the code that Mac had is probably better, at least where MAP_32BIT is not supported, trying to aim around ~0.5GB.  As it is, it will be 0 again on Mac and probably cause it to break again (if and only if the process happens to end up below 4GB in address space)?

Possibly a simpler solution would be:

```c++
// Try to request one that is close to (0.5 GB away) our memory location.
// We use a dummy global variable to give us a good location to start from.
if ((uintptr_t) &hint_location >= 0x100000000ULL)
	map_hint = (char *)round_page((char *)&hint_location - 0x20000000);
#if !defined(MAP_32BIT)
else
	map_hint = (char *)round_page(0x20000000);
#endif
```

-[Unknown]