Some functions don't have the `FunctionType` set. We can't look these up
and won't be able to call them, so ignore them when caching the function
names.

This does fix the failures caused by
https://github.com/llvm/llvm-project/pull/153160 mentioned in
https://github.com/llvm/llvm-project/pull/153160#issuecomment-3183062431.
However, in `lldb-shell::msstl_smoke.cpp` there's another failure not
introduced by #153160 (fixed with #153386).

This patch fixes:

  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:647:3:
  error: 'llvm::Expected' may not intend to support class template
  argument deduction [-Werror,-Wctad-maybe-unsupported]

  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:677:3:
  error: 'llvm::Expected' may not intend to support class template
  argument deduction [-Werror,-Wctad-maybe-unsupported]

Tag types like stucts or enums didn't have a declaration attached to
them. The source locations are present in the IPI stream in
`LF_UDT_MOD_SRC_LINE` records:

```
   0x101F | LF_UDT_MOD_SRC_LINE [size = 18, hash = 0x1C63]
            udt = 0x1058, mod = 3, file = 1, line = 0
   0x2789 | LF_UDT_MOD_SRC_LINE [size = 18, hash = 0x1E5A]
            udt = 0x1253, mod = 35, file = 93, line = 17069
```

The file is an ID in the string table `/names`:

```
     ID | String
      1 | '\<unknown>'
     12 | 'D:\a\_work\1\s\src\ExternalAPIs\WindowsSDKInc\c\Include\10.0.22621.0\um\wingdi.h'
     93 | 'D:\a\_work\1\s\src\ExternalAPIs\WindowsSDKInc\c\Include\10.0.22621.0\um\winnt.h'
```

Here, we're not interested in `mod`. This would indicate which module
contributed the UDT.

I was looking at Rustc's PDB and found that it uses `<unknown>` for some
types, so I added a check for that.

This makes two DIA PDB shell tests to work with the native PDB plugin.

---------

Co-authored-by: Michael Buch <michaelbuch12@gmail.com>

Relands #152295.

Checking for the overloads did not account for them being out of order.
For example, [the failed
output](https://github.com/llvm/llvm-project/pull/152295#issuecomment-3177563247)
contained the overloads, but out of order. The last commit here fixes
that by using `-DAG`.

---------

Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>

Reverts llvm/llvm-project#152295

This adds the ability for functions to be matched by their basename.

Before, the globals were searched for the name. This works if the full
name is available but fails for basenames.
PDB only includes the full names of functions, so we need to cache all
basenames. This is (again) very similar to
[SymbolFilePDB](https://github.com/llvm/llvm-project/blob/b242150b075a8a720b00821682a9469258bbcd30/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp#L1291-L1383).
There are two main differences:

- We can't just access the parent of a function to determine that it's a
member function - we need to check the type of the function, and its
"this type".
- SymbolFilePDB saved the full method name in the map. However, when
searching for methods, only the basename is passed, so the function
never found any methods.

Fixes #51933.

---------

Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>

Languages other than C/C++ don't necessarily emit mangled names in the
`UniqueName` field of type records. Rust specifically emits a unique ID
that doesn't contain the name.

For example, `(i32, i32)` is emitted as

```llvm
!266 = !DICompositeType(
  tag: DW_TAG_structure_type, name: "tuple$<i32,i32>", file: !9, size: 64, align: 32,
  elements: !267, templateParams: !17, identifier: "19122721b0632fe96c0dd37477674472"
)
```

which results in

```
  0x1091 | LF_STRUCTURE [size = 72, hash = 0x1AC67] `tuple$<i32,i32>`
           unique name: `19122721b0632fe96c0dd37477674472`
           vtable: <no type>, base list: <no type>, field list: 0x1090
           options: has unique name, sizeof 8
```

In C++ with Clang and MSVC, a structure similar to this would result in
```
   0x136F | LF_STRUCTURE [size = 44, hash = 0x30BE2] `MyTuple`
            unique name: `.?AUMyTuple@@`
            vtable: <no type>, base list: <no type>, field list: 0x136E
            options: has unique name, sizeof 8
```

With this PR, if a `UniqueName` is encountered that couldn't be parsed,
it will fall back to using the undecorated (→ do the same as if the
unique name is empty/unavailable).

I'm not sure how to test this. Maybe compiling the LLVM IR that rustc
emits?

Fixes #152051.

`FindNamespace` was not implemented for `SymbolFileNativePDB`. Without
it, it wasn't possible to lookup items through namespaces when
evaluating expressions.

This is mostly the same as in
[SymbolFilePDB](https://github.com/llvm/llvm-project/blob/f1eb869bae2ab86726ee3a5a5c7980d5b2acbd5d/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp#L1664-L1696)
as well as
[PDBAstParser](https://github.com/llvm/llvm-project/blob/f1eb869bae2ab86726ee3a5a5c7980d5b2acbd5d/lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp#L1126-L1150):
The AST parser/builder saves the created namespaces in a map to lookup
when a namespace is requested.

This is working towards making
[Shell/SymbolFile/PDB/expressions.test](https://github.com/llvm/llvm-project/blob/f1eb869bae2ab86726ee3a5a5c7980d5b2acbd5d/lldb/test/Shell/SymbolFile/PDB/expressions.test)
pass with the native PDB plugin.

Initially suggested in
https://github.com/llvm/llvm-project/pull/149305#issuecomment-3113413702
- this PR adds the setting `plugin.symbol-file.pdb.use-native-reader`.
It doesn't remove support for `LLDB_USE_NATIVE_PDB_READER` to allow some
backwards compatibility. This was the suggested way to use the native
reader - changing that would mean users who set this, now use the DIA
reader. The setting has priority over the environment variable, though.
If the default gets flipped on Windows, the environment variable could
probably be removed as well.

This would make it possible to test both native PDB and DIA PDB in the
API tests (see linked PR).

Previously, `type lookup` for types in namespaces didn't work with the
native PDB plugin, because `FindTypes` would only look for types whose
base name was equal to their full name. PDB/CodeView does not store the
base names in the TPI stream, but the types have their full name (e.g.
`std::thread` instead of `thread`). So `findRecordsByName` would only
return types in the top level namespace.

This PR changes the lookup to go through all types and check their base
name. As that could be a bit expensive, the names are first cached
(similar to the function lookup in the DIA PDB plugin). Potential types
are checked with `TypeQuery::ContextMatches`.

To be able to handle anonymous namespaces, I changed
`TypeQuery::ContextMatches`. The [`TypeQuery`
constructor](https://github.com/llvm/llvm-project/blob/9ad7edef4276207ca4cefa6b39d11145f4145a72/lldb/source/Symbol/Type.cpp#L76-L79)
inserts all name components as `CompilerContextKind::AnyDeclContext`. To
skip over anonymous namespaces, `ContextMatches` checked if a component
was empty and exactly of kind `Namespace`. For our query, the last check
was always false, so we never skipped anonymous namespaces. DWARF
doesn't have this problem, as it [constructs the context
outside](https://github.com/llvm/llvm-project/blob/abe93d9d7e891a2a6596ddb0c6324280137c89dc/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp#L154-L160)
and has proper information about namespaces. I'm not fully sure if my
change is correct and that it doesn't break other users of `TypeQuery`.

This enables `type lookup <type>` to work on types in namespaces.
However, expressions don't work with this yet, because `FindNamespace`
is unimplemented for native PDB.