cgmemmgr: CodeModel-aware memory management

[xal-0]

As described in #60245, we're unable to use the optimized memory manager on architectures where the default CodeModel is not Large. Since mmap() will generally put new mappings close to each other, allocations will succeed until the address space becomes fragmented enough that an RW allocation lands sufficiently far from the corresponding RX allocation, such that a relocation in the code fails.

This PR implements a new JLJITLinkMemoryManager, which is intended to have lower memory use than orc::MapperJITLinkMemoryManager and support non-large code models, unlike the old Julia CG memory manager. We accomplish this by reserving a block in the address space that is smaller than the maximum distance for relocations on the current architecture, putting the code and data sections inside this block:

    v-- 2^JULIA_CGMEM_BLOCK_SIZE --v

 ---+---------------------+--------+----
    | RX                  | RW     |
 ---+---------------------+--------+----

We make allocations inside the RX and RW regions (read-only data goes into the RX region for compactness) until one or the other is full, then we unmap unused pages and make a new block elsewhere. The size of a block can be set with JULIA_CGMEM_BLOCK_SIZE, while the ratio of RX to RW within the block is fixed, based on empirical measurements. If an allocation requires more space than is available in a single block, contiguous pages are allocated at an arbitrary address for it.

TODOs:

• Basic stress tests with small block size
• Test all implemented ROBlockMappers
• Add a fallback to MapperJITLinkMemoryManager. This is important on mac, where it's more likely that we aren't able to make a temporary file for DualBlockMapper.
• Better tests that intentionally fragment the address space
• Add a ProtectionKeyMapper that uses MAP_JIT on macOS and pkeys on linux. Still want to do this, but can do it later.

[gbaraldi]

We should look into upstreaming this

[vtjnash]

might be worth adding MAP_FIXED_NOREPLACE too, where that exists (Linux mainly, though treated as equivalent to MAP_FIXED in 4.17 to 4.19 by accident)

[vtjnash]

Why aren't we mimicking the mmap API and passing the hint here too?

[xal-0]

To work around not having MEM_RESERVE_PLACEHOLDER until we bump the minimum Windows version, I have map_reserve return 0. CodeAllocator::map_blocks still calls map_rw with a non-zero address (it takes the 0 from map_reserve and adds the size of the RX region), so I'd have to ifdef that in two places instead.

[vtjnash]

Wow, an API to do exactly this feature, that looks very nice to have MemExtendedParameterAddressRequirements