The `current_module` pointer here was never set, but we check it when
looping over the `target_modules` list. Presumably the intention was to
avoid calling `LookupInModule` if we already found the type in the
current module. This patch removes this `current_module`. If we decide
the output below is not what the user should see, we can revisit the
implementation.

Current output:
```
(lldb) im loo -vt Foo --all
Best match found in /Users/jonas/Git/llvm-worktrees/llvm-project/a.out:
id = {0x00000037}, name = "Foo", byte-size = 1, decl = foo.cpp:1, compiler_type = "struct Foo {
}"

1 match found in /Users/jonas/Git/llvm-worktrees/llvm-project/a.out:
id = {0x00000037}, name = "Foo", byte-size = 1, decl = foo.cpp:1, compiler_type = "struct Foo {
}"
```
which seems fine.

Note, there can be multiple matches *within* the current module, so if
we did the naive thing of skipping the `current_module` when printing
with `--all`, then we would miss some matches.

When starting an MCP protocol server that uses unix sockets as the
transport, a local `'[0.0.0.0]:0'` file is used instead of the supplied
socket path, e.g:
```
(lldb) protocol-server start MCP accept:///tmp/some/path.sock
MCP server started with connection listeners: unix-connect://[0.0.0.0]:0
(lldb) shell ls '[*'
[0.0.0.0]:0
```

This change makes it so that the URI path is used if the socket protocol
is `ProtocolUnixDomain`:
```
(lldb) protocol-server start MCP accept:///tmp/some/path.sock
MCP server started with connection listeners: unix-connect:///tmp/some/path.sock
```

It was assuming that for any location M.N, N was always less than the
number of breakpoint locations. But if you rebuild the target and rerun
multiple times, when the section backing one of the locations is no
longer valid, we remove the location, but we don't reuse the ID. So you
can have a breakpoint that only has location 1.3. The num_locations
check would say that was an invalid location.

### Summary
Currently, if the setting `interpreter.save-transcript` is enabled,
whenever we call "statistics dump", it'll default to reporting a huge
list of transcripts which can be a bit noisy. This is because the
current check `GetIncludeTranscript` returns `!GetSummaryOnly()` by
default if no specific transcript-setting option is given in the
statistics dump command (ie. `statistics dump --transcripts=false` or
`statistics dump --transcripts=true`). Then when
`interpreter.save-transcript` is enabled, this saves a list of
transcripts, and the transcript list ends up getting logged by default.

These changes default the option to log transcripts in the `statistics
dump` command to "false". This can still be enabled via the
`--transcripts` option if users want to see a transcript. Since
`interpreter.save-transcript` is false by default, the main delta is
that if `interpreter.save-transcript` is true and summary mode is false,
we now disable saving the transcript.

This also adds a warning to 'statistics dump --transcript=true' when
interpreter.save-transcript is disabled, which should help users
understand
why transcript data is empty.

### Testing

#### Manual testing
Tested with `settings set interpreter.save-transcript true` enabled at
startup on a toy hello-world program:
```
(lldb) settings set interpreter.save-transcript true
(lldb) target create "/home/qxy11/hello-world/a.out"
Current executable set to '/home/qxy11/hello-world/a.out' (x86_64).
(lldb) statistics dump
{
  /* no transcript */
}
(lldb) statistics dump --transcript=true
{
"transcript": [
    {
      "command": "statistics dump",
      "commandArguments": "",
      "commandName": "statistics dump",
      "durationInSeconds": 0.0019650000000000002,
      "error": "",
      "output": "{...
    },
    {
      "command": "statistics dump --transcript=true",
      "commandArguments": "--transcript=true",
      "commandName": "statistics dump",
      "timestampInEpochSeconds": 1750720021
    }
  ]
}
```
Without `settings set interpreter.save-transcript true`:
```
(lldb) target create "/home/qxy11/hello-world/a.out"
Current executable set to '/home/qxy11/hello-world/a.out' (x86_64).
(lldb) statistics dump
{
  /* no transcript */
}
(lldb) statistics dump --transcript=true
{
  /* no transcript */
}
warning: transcript requested but none was saved. Enable with 'settings set interpreter.save-transcript true'
```

#### Unit tests
Changed unit tests to account for new expected default behavior to
`false`, and added a couple new tests around expected behavior with
`--transcript=true`.
```
lldb-dotest -p TestStats ~/llvm-sand/external/llvm-project/lldb/test/API/commands/statistics/basic/
```

Rather than having one MCP server per debugger, make the MCP server
global and pass a debugger id along with tool invocations that require
one. This PR also adds a second tool to list the available debuggers
with their targets so the model can decide which debugger instance to
use.

continuation of
[#142684](https://github.com/llvm/llvm-project/pull/142684) to show
plugin names.

From issue [#14258](https://github.com/llvm/llvm-project/issues/142581)

This PR adds an MCP (Model Context Protocol ) server to LLDB. For
motivation and background, please refer to the corresponding RFC:
https://discourse.llvm.org/t/rfc-adding-mcp-support-to-lldb/86798

I implemented this as a new kind of plugin. The idea is that we could
support multiple protocol servers (e.g. if we want to support DAP from
within LLDB). This also introduces a corresponding top-level command
(`protocol-server`) with two subcommands to `start` and `stop` the
server.

```
(lldb) protocol-server start MCP tcp://localhost:1234
MCP server started with connection listeners: connection://[::1]:1234, connection://[127.0.0.1]:1234
```

The MCP sever supports one tool (`lldb_command`) which executes a
command, but can easily be extended with more commands.

We now bubble up the expression evaluation diagnostics to the user and
also distinguish between "expression failed to parse/run" versus other
ways in which expressions didn't complete (e.g., setup errors, etc.).

Before:
```
(lldb) memory find -e "" 0x16fdfedc0 0x16fdfede0
error: expression evaluation failed. pass a string instead
(lldb) memory find -e "invalid" 0x16fdfedc0 0x16fdfede0
error: expression evaluation failed. pass a string instead
```

After:
```
(lldb) memory find -e "" 0x16fdfedc0 0x16fdfede0
error: Expression evaluation failed:
error: No result returned from expression. Exit status: 1
(lldb) memory find -e "invalid" 0x16fdfedc0 0x16fdfede0
error: Expression evaluation failed:
error: <user expression 0>:1:1: use of undeclared identifier 'invalid'
    1 | invalid
      | ^~~~~~~
```

(depends on https://github.com/llvm/llvm-project/pull/143686)

There were two issues previously preventing `memory find -e` expressions
to succeed when stopped in Swift frames:
1. We weren't getting the dynamic type of the result `ValueObject`.
   For Swift this would fail when we tried to produce a scalar value
   out of it because the static VO wasn't sufficient to get to the
integer value. Hence we add a call to
`GetQualifiedRepresentationIfAvailable`
(which is what we do for expressions in `OptionArgParser::ToAddress`
too).
2. We weren't passing an `ExecutionContextScope` to `GetByteSize`, which
   Swift relied on to get the size of the result type.

My plan is to add an API test for this on the Apple
`swiftlang/llvm-project` fork.

I considered an alternative where we use `OptionArgParser::ToAddress`
for `memory find -e` expressions, but it got a bit icky when trying to
figure out how many bytes we should copy out of the result into the
`DataBufferHeap` (currently we rely on the size of the result variable
type). This gets even trickier when we were to pass an expression that
was actually a hex digit or a number into `ToAddress`.

rdar://152113525