🍒[next][Serialized diagnostics] Record generated buffer contents in diagnostics files

[etcwilde]

Cherry-picking #5923 from stable/20221013 (which is a cherry-pick of #5901 into stable/20220421).

I've updated the current CIndex minor version appropriately to match where upstream LLVM is, but this will likely cause merge-conflicts sooner than later so this patch set should likely be upstreamed.

Extend the format for serialized diagnostic files (.dia) to allow for the contents of source files to be included inside the diagnostic files themselves. This enables producers of diagnostics files that generate source code as part of their build (e.g., a compiler that performs macro expansion) to provide that generated source code to consumers of diagnostics, treating it like a normal file (e.g., with diagnostics pointing into it) that isn't otherwise recorded anywhere on disk.

Source files with contents can, optionally, provide a source range that describes the "original" source range from which those contents are derived. This information is optional, but if present it can refer back to the source locations that triggered the creation of the generated source code, i.e., the use of a macro that caused macro expansion.

This change extends the libclang C APIs with access to the source file contents (via clang_getDiagnosticFileContents) and the original source range (via clang_getDiagnosticFileOriginalSourceRange).

The diagnostics file format, which has been stable for roughly a decade, is extended in a backward-compatible way by adding a new record, which existing clients (i.e., older libclang versions) will safely ignore. As such, we do not bump the diagnostics file format version at all.

At present, the Swift compiler is the only producer of source file content records, which uses them to provide macro-expansion buffers. The Swift repository contains tests that produce these records and verify their correctness via c-index-test.

We could consider introducing command-line flags to Clang to make it start producing these records, e.g., to capture macro-expansion buffers (as we're doing in Swift) or even to package up the contents of all source files that are referenced by serialized diagnostics, making the serialized-diagnostics file self-contained.

Implements the Clang side of rdar://103900370

[etcwilde]

@swift-ci please test

[etcwilde]

(I expect failures in Swift, but the rest of LLVM should build)