[lldb][Windows] CodeView loses module information

CodeView has no native equivalents for DWARF's `DW_TAG_module` and `DW_TAG_imported_module`. The corresponding `DIModule` and `DIImportedEntity` end up getting dropped entirely when emitting CodeView. This prevents us from determining: - which module any given symbol is in - which modules a given module imports Without this information, `SwiftASTContextForExpressions` can't load any module but the stdlib (which is [hardcoded](https://github.com/swiftlang/llvm-project/blob/6800a4d27272750e027d9e3a3a396424f36d73a8/lldb/source/Plugins/TypeSystem/Swift/SwiftASTContext.cpp#L10042)). The effect is that symbols outside of the stdlib can't be resolved in expressions. Experimenting with MSVC and C++ modules, I couldn't find any equivalent. This is unsurprising, since C++ modules are much less interesting to a debugger than Swift modules. ## Possible solutions We have a few major constraints: - Whatever we do needs to work with link.exe. This precludes certain approaches like creating a dummy synthetic module in the PDB stream or repurposing [the `ModuleName` field](https://llvm.org/docs/PDB/DbiStream.html#module-info-substream) in the DBI stream. - We can't extend CodeView in possibly-incompatible ways like introducing new record types in existing streams. This could break us in the future if those IDs are used, and could break existing tools that parse CodeView. Given that, some possibilities are: 1. Custom PDB stream. This would require a post-processing step to run after the link, since link.exe doesn't expose knobs to add custom streams. 2. A new section in the binary. 3. A dummy object file (as in an actual object file, rather than a synthetic reference to one in the PDB stream, which we rejected above due to linker incompatibility). 4. Parsing module names out of symbol names (very ugly, probably fragile, but better than nothing in a pinch) 5. Repurposing the `S_OBJNAME` record to identify each compiland's module. I prefer this option. Starting with the major downsides of using `S_OBJNAME`: - It's non-standard - It can't be upstreamed, since it's actually written by Clang. However, the upsides are compelling: - Currently unset in Swift - *Much less* moving parts compared to the other options - Not currently used by anything beyond display in llvm-pdbutil ### Imports This would give us the module for a a symbol, but not help with resolving imports. However, given a module, we could parse its imports from the `INPUT_BLOCK` after fetching the module from the `swiftast` section.