Sanity check huge block sizes before using them as munmap() lengths

[jvoisin]

zend_mm_huge_list nodes are allocated with zend_mm_alloc_heap(), from the very heap they describe, so a heap overflow can reach them. Their size field is then handed to munmap() in three places:

• zend_mm_free_huge(), directly via zend_mm_chunk_free(),
• the huge block loop in zend_mm_shutdown(), likewise,
• zend_mm_realloc_huge(), which takes it as old_size and passes it to zend_mm_chunk_truncate(), which unmaps the tail with munmap(addr + new_size, old_size - new_size).

The ptr is constrained a bit, as it has to match the pointer being freed and is checked for chunk alignment, but size is used as-is. Corrupting it turns a free of a legitimate huge block into an unmap of an arbitrary amount of adjacent address space, which a later mmap() can then occupy.

This commit bounds it before use: A live huge block has to satisfy three cheap invariants: its size is not zero, it is a multiple of REAL_PAGE_SIZE (since it was produced by ZEND_MM_ALIGNED_SIZE_EX(size, REAL_PAGE_SIZE)), and it is still accounted for in heap->real_size, which is only decremented after the block has been freed. This narrows the primitive rather than removing it, as doing so would be more invasive.

This commit was validated under gdb by tampering with size on a live 4MB block and freeing it: 0, 0x400001 (unaligned) and 0x800000 (exceeding a 6MB real_size) all abort with "zend_mm_heap corrupted", where all three were previously passed to munmap().

[jvoisin]

Part of #14083