Let GeneralPurposeAllocator retain metadata to report more double frees

[mattbork]

Currently GeneralPurposeAllocator can only properly report double frees for small allocations from active buckets (buckets that weren't emptied at any point). Double frees for other small allocations and for all large allocations fall through to the "Invalid free" panic in resizeLarge (assuming config.safety is true). This will show a stack trace for the current free, but it can't show anything for the allocation or the first free. It also can't be recovered from, unlike properly reported double frees, and this may make debugging more onerous.

I've added a new flag, config.retain_metadata, that makes GeneralPurposeAllocator retain all empty buckets in a separate list and never remove entries from the large_allocations hash map (only mark them as freed). This way any double free of memory actually allocated from this allocator will always be able to find a set of stack traces to report. The extra storage for the empty bucket list in GeneralPurposeAllocator and the second stack trace and other bookkeeping in LargeAlloc is spent only when retain_metadata is set. Further, the performance of small allocations is not affected at all. However, because entries are never removed from large_allocations, lookup is likely to be slower as the map gets bigger. Leaving entries in the hash map was the simplest option and requires no extra allocations be done when freeing large objects, but maintaining a second hash map for dead large allocations is another option if the effect on performance is too high.

Another benefit of retaining metadata is that double frees can eventually be caught without having to use config.never_unmap and leak memory (all retained metadata is easily freed when the allocator is freed). For now, until #4298 is finished, retain_metadata should be used with never_unmap or else memsets in the allocator interface will cause segfaults. But in either case, because we're retaining metadata, the memory leaked by never_unmap can actually now be freed when the metadata is freed because we know exactly what memory was left deliberately unfreed. This should allow checking for double frees during only portions of a long running program with ballooning memory use. To that end, I added a public function flushRetainedMetadata that will free all retained metadata and, if never_unmap is set, recover the leaked memory as well. It is present only when retain_metadata is true.

I'd like to add tests for actually detecting and recovering from double frees but because the stack traces are logged immediately to stderr, I don't know if there's any way to keep a test from being marked as failing. Instead, I have a rather invasive test that just checks that metadata is kept and marked correctly after a free, and that all memory leaked by never_unmap is ultimately freed. For general stress testing, I also ran all of test-std with the std.testing.allocator modified to set retain_metadata (with and then without never_unmap set) and test_runner.zig modified to use a second GeneralPurposeAllocator as the backing_allocator for the testing allocator in order catch any leaks of metadata.

Since this is a large addition to somewhat intricate code that is also a basic element of the standard library, I'm happy to break down my changes in more detail if helpful.

[andrewrk]

Oops, thought this was an issue, didn't realize you already implemented it. Very cool, will check this out later today :)