feature/asan-gc-poisoning: Better memory checks using AddressSanitizer

[Vibhav Pant <vibhavp@gmail.com>]

As part of trying to debug the deluge of GC borks in
scratch/comp-static-data, I took a slight detour through Emacs' memory
management code and the sanity checks that it optionally comes with.
The changes in feature/asan-gc-poisoning attempt to augment the
latter, specifically when Emacs is built with '-fsanitize=address'.

When enabled, almost all memory management operations are instrumented
with calls to ASan's "(un)poisoning" functions, which allow ASan to
mark allocated but not freed addresses as "poisoned", triggering
errors whenever they have been accessed. The idea behind this is to
add another layer of checks against code that makes use of free lists
and arena based allocators, only allowing access to regions of the
memory that are actually intended to be accessible (aka "unpoisoned"
in ASan parlance) by non alloc-related C code. An instance of this is
any object on a free list, or a vectorlike with the type PVEC_FREE (we
do abort whenever we come across such a vector, but this ideally
catches the bug way earlier in the flow, and therefore closer to the
source of the actual problem). Additional documentation explaining
this feature is available both on src/alloc.c and the "Running Emacs
with address sanitization" section in etc/DEBUG.

The branch bootstraps successfully both with native-comp enabled and
disabled, and passes everything on the test suite on my machine.
Because enabling Address Sanitizer comes with a significant
performance + memory overhead, using it as a daily driver isn't
without a decent bit of sluggishness, although building with -O2 and
native compilation seems to help, at least a little.
I plan to get install this in `master` soon, so both feedback and
testing from other users would be greatly appreciated. The current
codebase quite likely does everything alloc related correctly, so an
ASan error might be indicative of a snag in this branch instead of
Emacs itself (fingers crossed for the opposite, however :)).

Thanks,
Vibhav
-- 
Vibhav Pant
vibhavp@gmail.com
GPG: 7ED1 D48C 513C A024 BE3A  785F E3FB 28CB 6AB5 9598