This reverts 4d10c1165442cbbbc0017b48fcdd7dae1ccf3678 and its two
dependent commits: e6b9805b574bb5c90263ec7fbcb94df76d2807a4 and
c243406a695ca056a07ef4064b0f9feee7685320, see discussion in
https://github.com/llvm/llvm-project/pull/165598#issuecomment-3563825509.

In debug-info we soon have the need to print names using the full scope
of the entity (see discussion in
https://github.com/llvm/llvm-project/pull/159592). Particularly, when a
structure is scoped inside a function, we'd like to emit the name as
`func()::foo`. `CGDebugInfo` uses the `TypePrinter` to print type names
into debug-info. However, `TypePrinter` stops (and ignores)
`DeclContext`s that are functions. I.e., it would just print `foo`.
Ideally it would behave the same way `printNestedNameSpecifier` does.
The FIXME in
https://github.com/llvm/llvm-project/blob/47c1aa4cef638c97b74f3afb7bed60e92bba1f90/clang/lib/AST/TypePrinter.cpp#L1520-L1521
motivated this patch.

See https://github.com/llvm/llvm-project/pull/168533 for how this will
be used by `CGDebugInfo`. The plan is to introduce a new
`PrintingPolicy` that prints anonymous entities using their full scope
(including function/anonymous scopes) and the mangling number.

See the attached test for example.

MSVC supports an extension allowing to delete an array of objects via
pointer whose static type doesn't match its dynamic type. This is done
via generation of special destructors - vector deleting destructors.
MSVC's virtual tables always contain a pointer to the vector deleting
destructor for classes with virtual destructors, so not having this
extension implemented causes clang to generate code that is not
compatible with the code generated by MSVC, because clang always puts a
pointer to a scalar deleting destructor to the vtable. As a bonus the
deletion of an array of polymorphic object will work just like it does
with MSVC - no memory leaks and correct destructors are called.

This patch will cause clang to emit code that is compatible with code
produced by MSVC but not compatible with code produced with clang of
older versions, so the new behavior can be disabled via passing
-fclang-abi-compat=21 (or lower).

This is yet another attempt to land vector deleting destructors support
originally implemented by
https://github.com/llvm/llvm-project/pull/133451.

This PR contains fixes for issues reported in the original PR as well as
fixes for issues related to operator delete[] search reported in several
issues like

https://github.com/llvm/llvm-project/pull/133950#issuecomment-2787510484
https://github.com/llvm/llvm-project/issues/134265

Fixes https://github.com/llvm/llvm-project/issues/19772

Similar to previous no transitive changes to decls, types, identifiers
and source locations (
https://github.com/llvm/llvm-project/pull/92083
https://github.com/llvm/llvm-project/pull/92085
https://github.com/llvm/llvm-project/pull/92511
https://github.com/llvm/llvm-project/pull/86912
)

This patch does the same thing for MacroID and PreprocessedEntityID.

---

### Some background

Previously we record different IDs linearly. That is, when writing a
module, if we have 17 decls in imported modules, the ID of decls in the
module will start from 18. This makes the contents of the BMI changes if
the we add/remove any decls, types, identifiers and source locations in
the imported modules.

This makes it hard for us to reduce recompilations with modules. We want
to skip recompilations as we think the modules can help us to remove
fake dependencies. This can be done by split the ID into <ModuleIndex,
LocalIndex> pairs.
This is ALREADY done for several different ID above. We call it
non-casacading changes
(https://clang.llvm.org/docs/StandardCPlusPlusModules.html#experimental-non-cascading-changes).
Our internal users have already used this feature and it works well for
years.

Now we want to extend this to MacroID and PreprocessedEntityID. This is
helpful for us in the downstream as we allowed named modules to export
macros. But I believe this is also helpful for header-like modules if
you'd like to explore the area.

And also I think this is a nice cleanup too.

---

Given the use of MacroID and PreprocessedEntityID are not as complicated
as other IDs in the above series, I feel the patch itself should be
good. I hope the vendors can test the patch to make sure it won't affect
existing users.

Close https://github.com/llvm/llvm-project/issues/166068

The cause of the problem is that we would import initializers and
pending implicit instantiations from other named module. This is very
bad and it may waste a lot of time.

And we didn't observe it as the weak symbols can live together and the
strong symbols would be removed by other mechanism. So we didn't observe
the bad behavior for a long time. But it indeeds waste compilation time.

This PR implements `CompilerInstanceWithContext` to improve by-name
dependency queries.

Cases exist where we query the dependency of different names, with
otherwise identical working directory and compile command line inputs.
In these cases, we can create one `CompilerInstance`, whose lifetime is
the same as the dependency scanning worker, and reuse the same compiler
instance to complete the queries. This way we reduce the amount of
header search we need to perform per query, since the already completed
header search results are cached in the compiler instance.

Using a microbenchmark on a prototype of this implementation, we are
seeing a scanning performance improvement of about 20%. The
microbenchmark scans a Swift file that imports everything importable.
When measuring against a set of internal project builds, the geo mean of
total build time improvement is around 1.02x to 1.04x depending on
whether the module caches are populated or not.

Part of work for rdar://136303612.

Fixes #165445.

Fixes a crash when `ASTWriter::GenerateNameLookupTable` processes enum
constants from C++20 header units.

The special handling for enum constants, introduced in fccc6ee, doesn't
account for declarations whose owning module is a C++20 header unit. It
calls `isNamedModule()` on the result of
`getTopLevelOwningNamedModule()`, which returns null for header units,
causing a null pointer dereference.

All builtin Clang headers need to be covered by the modulemap.

This fixes https://github.com/llvm/llvm-project/issues/166173