[defmacro-jam]

Fixes #319.

VMChunkCreate (code/arenavm.c) maps the chunk structure's grain with vmArenaMap, which adds it to arena->committed. When ChunkInit then failed, failChunkInit unmapped the grain with the raw VMUnmap, which does not subtract it. Each grow refused at the commit limit therefore left the arena over-counting committed memory, and mps_arena_destroy later failed AVER(arena->committed == VMMapped(VMArenaVM(vmArena))) at arenavm.c:799. failChunkInit now calls VMChunkFinish. That function unmaps the chunk's overhead through vmArenaUnmap, covering the chunk structure and any bit tables VMChunkInit mapped, and then finishes the VM.

That change also needs ChunkInit (code/tract.c) to stop calling the class's chunkFinish when ArenaFreeLandInsert fails. Otherwise that failure finishes the chunk twice. The old code already did that, so this fixes a second problem:

• VMChunkFinish released the VM.
• Then failChunkInit called VMUnmap and VMFinish on the stack copy of the same VM.
• On Windows the second call is VirtualFree(MEM_DECOMMIT) on released address space, which I read as failing AVER(b != 0) at vmw3.c:225.
• On POSIX it is a MAP_FIXED mapping and a second munmap over a range another thread may since have been given.

The client arena's chunkFinish does nothing and its clientChunkCreate has nothing to undo, so moving the responsibility to the caller changes nothing there.

Tested on macOS arm64 (16 KiB pages) with clang:

• The reproducer in arenavm.c: VMChunkCreate leaks arena->committed when ChunkInit fails, then mps_arena_destroy asserts at arenavm.c:799 #319 passes in the cool and hot varieties. mps_arena_destroy completes without the assertion, where unchanged master fails it.
• arenacv, fotest, apss, locusss, mpmss and amcss pass in the cool variety.

The ArenaFreeLandInsert failure path and Windows have not been run.