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

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

WG14 N3469 changed _Lengthof to _Countof but it also introduced the
<stdcountof.h> header to expose a macro with a non-ugly identifier. GCC
vends this header as part of the compiler implementation, so Clang
should do the same.

Suggested-by: Alejandro Colomar <alx@kernel.org>

These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.

This reverts commit 64bb60a471a5ddc9c9bec413c65fdab730a1e4b0.

Revert to give more time affected parties to adjust to the change.

According to the documentation
> A header declaration that does not contain `exclude` nor `textual`
specifies a header that contributes to the enclosing module.

Which means that `exclude` and `textual` header don't contribute to the
enclosing module and their presence isn't required to build such a
module. The keywords tell clang how a header should be treated in a
context of the module but they don't add headers to the module.

When a textual header *is* used, clang still emits "file not found"
error pointing to the location where the missing file is included.

Instead of eagerly populating the `clang::ModuleMap` when looking up a
module by name, this patch changes `HeaderSearch` to only load the
modules that are actually used.

This introduces `ModuleMap::findOrLoadModule` which will load modules
from parsed but not loaded module maps. This cannot be used anywhere
that the module loading code calls into as it can create infinite
recursion.

This currently just reparses module maps when looking up a module by
header. This is fine as redeclarations are allowed from the same file,
but future patches will also make looking up a module by header lazy.

This patch changes the shadow.m test to use explicitly built modules and
`#import`. This test and the shadow feature are very brittle and do not
work in general. The test relied on pcm files being left behind by prior
failing clang invocations that were then reused by the last invocation.
If you clean the cache then the last invocation will always fail. This
is because the input module map and the `-fmodule-map-file=` module map
are parsed in the same module scope, and `-fmodule-map-file=` is
forwarded to implicit module builds. That means you are guaranteed to
hit a module redeclaration error if the TU actually imports the module
it is trying to shadow.

This patch changes when we load A2's module map to after the `A` module
has been loaded, which sets the `IsFromModuleFile` bit on `A`. This
means that A2's `A` is skipped entirely instead of creating a shadow
module, and we get textual inclusion. It is possible to construct a case
where this would happen before this patch too.

An upcoming patch in this series will rework shadowing to work in the
general case, but that's only possible once header -> module lookup is
lazy too.

Static analysis flagged this code for using copy when we could use
std::move.

Worth noting that CD.Message is a StringRef but Conflict.Message is
std::string. Otherwise I would have used a temporary in place and avoid
a local variable.

Static analysis flagged this code as causing a copy when we never modify
ModName and therefore we can use const auto & and avoid copying.

Now that we have ModuleMapFile.cpp which parses module maps, it's
confusing what ModuleMap::parseModuleMapFile actually does. HeaderSearch
already called this loading a module map, so consistently use that term
in ModuleMap too.

An upcoming patch will allow just parsing a module map without loading
the modules from it.