[llvm] [Clang][CodeGen] Introduce the AllocToken SanitizerKind (PR #162098)

[Marco Elver via llvm-commits]

melver wrote:

> Due to the time zone difference, I've gone ahead and reverted this patch and its dependent patch (#162099)

Sigh, this is a brittle test, or rather an unfortunate side-effect of incrementally building & testing on a CI where the test outputs are not cleared. I was able to reproduce this when I checked out 93f2e0a4, then checked out this change, and retested with the zorg scripts. Then, if I run:
```
rm -rf zorg-test/llvm_build_asan_ubsan/tools/clang/test/Preprocessor/Output/print-header-json.c.tmp/
```
And rerun the tests, the tests pass:
```
../zorg-test/llvm_build_asan_ubsan/bin/llvm-lit -v clang/test/Preprocessor/print-header-json.c
-- Testing: 1 tests, 1 workers --
PASS: Clang :: Preprocessor/print-header-json.c (1 of 1)

Testing Time: 3.57s

Total Discovered Tests: 1
  Passed: 1 (100.00%)
```

We could try to fix the test to clear the cache dir or fix the test scripts. I suspect fixing the test is the better option, because everyone who does incremental build + test will have this problem.

Summary of the problem is this: After a patch (such as one adding new sanitizer kind) that changes the binary format of PCMs (because they track codegen options), reusing a stale cached PCM is no longer binary-compatible. Here, adding a new sanitizer option altered the implicit binary layout of the serialized LangOptions. The build & test system is oblivious to this. When the new compiler attempted to read the old module file, it misinterpreted the data due to the layout mismatch, resulting in a heap-buffer-overflow.

TLDR; Clang's PCM binary format doesn't encode a version and attempting to load version-incompatible PCMs from previous test invocations after an implicit change results in a heap buffer overflow and assorted failures.

https://github.com/llvm/llvm-project/pull/162098