Support DualMapAllocator on aarch64 macOS, and add MapJITAllocator

[xal-0]

In conjunction with #60105, this change brings our optimized memory management over to aarch64 macOS, where JITLink is the only supported linker.

First, this changes the way we test for DualMapAllocator support so that it will be selected on macOS again. We are not allowed to mmap RX MAP_SHARED pages directly, but it's okay to mmap with no protections and mprotect afterwards, so test for that.

However, when it is supported, we always prefer to use the new MapJITAllocator for executable pages. MapJITAllocator uses MAP_JIT pages, which are "seen" by every thread as either RX or RW, according to the value of a special thread-local register. When we use this allocator, only a single mapping is required, no copies are necessary when JITting, and no mprotect syscalls are necessary to finalize the code. Other threads can continue to execute code in the MAP_JIT region while we write to it, since only the thread that is JITting has the jit_rw flag enabled.

Bootstrapping sees about a ~10% reduction in peak RSS and run time, with bigger improvements on very JIT-heavy workloads.

[xal-0]

I'll need to tweak the allocator interface more than I originally thought. I'd like to keep using the small code model on aarch64, but it isn't possible without merging the three independent allocators we use at the moment. We need to make sure the MAP_JIT region falls within 2^32 bytes of the RO and RW mappings. If we have that, we can look at using a less pessimistic code model on x86_64, too.

[xal-0]

Putting this on hold until I have the time to make a code model-aware allocator. #60031 is no longer blocked by memory manager issues, so we can keep using the MapperJITLinkMemoryManager on aarch64.