TLDR
----------
This PR adds `--no-lldbinit` as a new CLI flag to the `lldb-dap`

Motivation
-----------
Rcently Users reported being unable to control `.lldbinit` file sourcing
when debugging through VS Code.
https://github.com/llvm/llvm-project/issues/155802.
VS Code extensions cannot easily inject custom parameters into the DAP
initialize request. Adding `--no-lldbinit` as a CLI flag solves this
problem by allowing the decision to skip `.lldbinit` files to be made at
debugger startup, before any initialization requests are processed.
VS Code extensions can control this behavior by specifying the flag
through `debugAdapterArgs` or similar mechanisms in launch
configurations.

```
{
  "type": <extension-type>,
  "request": "launch", 
  "name": "Debug with --no-lldbinit",
  "program": "${workspaceFolder}/your-program",
  "debugAdapterArgs": ["--no-lldbinit"]
}
```
Summary
----------
This PR introduces a new command-line flag `--no-lldbinit` (with alias
`-x`) to `lldb-dap`. The flag prevents automatic parsing of `.lldbinit`
files during debugger initialization, giving users control over whether
their LLDB initialization scripts are loaded.

### Key Changes:

1. **CLI Option Definition** (`Options.td`): Added the `--no-lldbinit`
flag with `-x` alias
2. **Core Implementation** (`DAP.cpp`): Added support for storing and
using the no-lldbinit flag
3. **Initialization Handler** (`InitializeRequestHandler.cpp`): Modified
to respect the flag during debugger initialization
4. **Main Tool** (`lldb-dap.cpp`): Added argument parsing for the new
flag
5. **Test Infrastructure** (`dap_server.py & lldbdap_testcase.py`):
Enhanced test framework to support additional arguments

Test Plan
---------

### New Test Coverage (`TestDAP_launch.py`)

**Test Method:** `test_no_lldbinit_flag()`

**Test Strategy:**

1. **Setup**: Creates a temporary `.lldbinit` file with specific
settings that would normally be loaded
2.  **Execution**: Launches lldb-dap with the `--no-lldbinit` flag
3. **Verification**: Confirms that the settings from `.lldbinit` are NOT
applied, proving the flag works correctly

**Test Environment:**

*   Uses a temporary home directory with a custom `.lldbinit` file
* Sets specific LLDB settings (`stop-disassembly-display never`,
`target.x86-disassembly-flavor intel`)
* Launches debug adapter with `--no-lldbinit` flag via `additional_args`
parameter

**Validation Approach:**

* Executes `settings show stop-disassembly-display` command during
initialization
* Verifies the output does NOT contain "never" (which would indicate
`.lldbinit` was sourced)
*   Confirms that initialization commands are still executed properly

### Testing Infrastructure Enhancements

**File Modifications:**

* `dap_server.py`: Enhanced to accept `additional_args` parameter for
passing extra CLI flags
* `lldbdap_testcase.py`: Updated `build_and_create_debug_adapter()`
method to support additional arguments and environment variables

### Unit Test Integration

**Unit Test Updates** (`DAPTest.cpp`):

* Added initialization of the new flag in test setup to ensure
consistent test behavior

**Test Run**
<img width="1759" height="1373" alt="Screenshot 2025-08-29 at 5 56
18 PM"
src="https://github.com/user-attachments/assets/769b319a-5009-4ade-aff8-c5f548b38123"
/>

---------

Co-authored-by: Piyush Jaiswal <piyushjais@meta.com>

This adds new types for setExceptionBreakpoints and adds support for
`supportsExceptionFilterOptions`, which allows exception breakpoints to
set a condition.

While testing this, I noticed that obj-c exception catch breakpoints may
not be working correctly in lldb-dap.

Move the command plugins out of the DAP header and into their file. This
PR also renames the classes from "RequestHandler" to "Command". Although
they are implemented in terms of sending requests, they are not
"handlers".

This is more straight forward refactor of the startup sequence that
reverts parts of ba29e60f9a2222bd5e883579bb78db13fc5a7588. Unlike my
previous attempt, I ended up removing the pending request queue and not
including an `AsyncReqeustHandler` because I don't think we actually
need that at the moment.

The key is that during the startup flow there are 2 parallel operations
happening in the DAP that have different triggers.

* The `initialize` request is sent and once the response is received the
`launch` or `attach` is sent.
* When the `initialized` event is recieved the `setBreakpionts` and
other config requests are made followed by the `configurationDone`
event.

I moved the `initialized` event back to happen in the `PostRun` of the
`launch` or `attach` request handlers. This ensures that we have a valid
target by the time the configuration calls are made. I added also added
a few extra validations that to the `configurationeDone` handler to
ensure we're in an expected state.

I've also fixed up the tests to match the new flow. With the other
additional test fixes in 087a5d2ec7897cd99d3787820711fec76a8e1792 I
think we've narrowed down the main source of test instability that
motivated the startup sequence change.

This updates the `attach` request to the typed
`RequestHandler<protocol::AttachRequestArguments,
protocol::AttachResponse>`.

Added a few more overlapping configurations to
`lldb_dap::protocol::Configuration` that are shared between launching
and attaching.

There may be some additional code we could clean-up that is no longer
referenced now that this has migrated to use well defined types.

This PR changes how we treat the launch sequence in lldb-dap.

 - Send the initialized event after we finish handling the initialize
   request, rather than after we finish attaching or launching.
 - Delay handling the launch and attach request until we have handled
   the configurationDone request. The latter is now largely a NO-OP and
   only exists to signal lldb-dap that it can handle the launch and
   attach requests.
 - Delay handling the initial threads requests until we have handled
   the launch or attach request.
 - Make all attaching and launching synchronous, including when we have
   attach or launch commands. This removes the need to synchronize
   between the request and event thread.

Background:
https://discourse.llvm.org/t/reliability-of-the-lldb-dap-tests/86125

This reverts commit ba29e60f9a2222bd5e883579bb78db13fc5a7588.

As it broke tests on Windows on Arm: https://lab.llvm.org/buildbot/#/builders/141/builds/8500

********************
Unresolved Tests (2):
  lldb-api :: tools/lldb-dap/completions/TestDAP_completions.py
  lldb-api :: tools/lldb-dap/startDebugging/TestDAP_startDebugging.py
********************
Timed Out Tests (1):
  lldb-api :: tools/lldb-dap/send-event/TestDAP_sendEvent.py
********************
Failed Tests (6):
  lldb-api :: tools/lldb-dap/console/TestDAP_console.py
  lldb-api :: tools/lldb-dap/console/TestDAP_redirection_to_console.py
  lldb-api :: tools/lldb-dap/launch/TestDAP_launch.py
  lldb-api :: tools/lldb-dap/stackTrace/TestDAP_stackTrace.py
  lldb-api :: tools/lldb-dap/stackTraceDisassemblyDisplay/TestDAP_stackTraceDisassemblyDisplay.py
  lldb-api :: tools/lldb-dap/variables/children/TestDAP_variables_children.py

This PR changes how we treat the launch sequence in lldb-dap.

 - Send the initialized event after we finish handling the initialize
   request, rather than after we finish attaching or launching.
 - Delay handling the launch and attach request until we have handled
   the configurationDone request. The latter is now largely a NO-OP and
   only exists to signal lldb-dap that it can handle the launch and
   attach requests.
 - Delay handling the initial threads requests until we have handled
   the launch or attach request.
 - Make all attaching and launching synchronous, including when we have
   attach or launch commands. This removes the need to synchronize
   between the request and event thread.

Background:
https://discourse.llvm.org/t/reliability-of-the-lldb-dap-tests/86125

The module event indicates that some information about a module has
changed. The event is supported by the Emacs and Visual Studio DAP
clients. This PR adds support for emitting the event from lldb-dap.

Fixes #137058