ArcHeap checking (issue #161 follow-up)

Since the ArcHeap team released their tool, I ran it over mimalloc for a
day and it reported some issues. The three things I note are:

• The only two categories of problem it finds are overlapping-chunk (OC)
  and restricted-write (RW). So far none of the RW crashes it has found
  have reproduced outside of what AFL reported, so perhaps those are
  invalid tests, or only reproduce with the right initial randomness state.
  The ArcHeap paper doesn't appear to make a hard claim of no
  false-positives - just that they didn't see any. @jakkdu FYI in case this is
  of interest.

• One of the OC files it created seemingly enters an infinite loop and
  allocates ~7TB of virtual memory. I couldn't attach the debugger to
  it and it only happens every few runs.

• Another OC file hits its assert() every run. I presume that means
  it's a reliable overlap?

This is with MI_SECURE=4 and mimalloc v1.6.4.
The POC .c files are available.

Start with the available POC .c files and reproduce them against mimalloc v1.6.4 with MI_SECURE=4, using ArcHeap as reported. Investigate whether the OC infinite-loop/7TB allocation and recurring assert are reproducible, and compare the RW reports with AFL results. Done means documenting reliable overlaps, invalid tests, or a clear reproduction.