For dependency scanning, it would be useful to collect header search paths (provided on command-line via -I and friends) that were actually used during preprocessing. This patch adds that feature to HeaderSearch along with a new remark that reports such paths as they get used.
Previous version of this patch tried to use the existing LookupFileCache to report used paths via HitIdx. That doesn't work for ComputeUserEntryUsage (which is intended to be called *after* preprocessing), because it indexes used search paths by the file name. This means the values get overwritten when the code contains #include_next.
Note that HeaderSearch doesn't use HeaderSearchOptions::UserEntries directly. Instead, InitHeaderSearch pre-processes them (adds platform-specific paths, removes duplicates, removes paths that don't exist) and creates DirectoryLookup instances. This means we need a mechanism for translating between those two. It's not possible to go from DirectoryLookup back to the original HeaderSearch, so InitHeaderSearch now tracks the relationships explicitly.
Depends on D111557.
I suggest, more simply, "search path used:" (drop the "user-provided"). If you think it's useful for information purposes to know whether it was a user or system search path, I'd suggest using a select (in that case, maybe you want to add an optional "framework" descriptor, and/or "header map" when applicable, etc.).