Add condition, hitCondition, and logMessage to the Breakpoint type

首先定位 Breakpoint 和 SourceBreakpoint 类型定义并比较它们现有的字段，同时参考链接的 Debug Adapter Protocol 规范作为背景。添加 issue 中提出的三个可选字段，并验证协议定义仍与文档中记录的 request 和 response 类型保持一致。

Problem
The SourceBreakpoint type (request side) includes condition, hitCondition, and logMessage, but the Breakpoint type (response/event side) does not. This means when a debug adapter sends a breakpoint event, the client cannot determine whether the breakpoint is a logpoint or conditional breakpoint.

Consequence: Logpoints sent via breakpoint events render as regular breakpoints in the UI — losing the logpoint icon and confusing users. Conditional breakpoints similarly lose their condition decoration.

Proposed Change
Add three optional fields to the Breakpoint type, mirroring SourceBreakpoint:

interface Breakpoint {
// ... existing fields ...
condition?: string;
hitCondition?: string;
logMessage?: string;
}

Rationale
Symmetry: line and column already round-trip between SourceBreakpoint and Breakpoint. condition, hitCondition, and logMessage should too.
Backward compatible: All fields are optional — existing adapters and clients are unaffected.
Enables correct rendering: Clients can use logMessage presence to render logpoints (◇) vs breakpoints (●), and display conditions in hover/detail views.
Unblocks AI usecase: In developing AI capabilities for debugging, logpoints and conditional breakpoints are particularly requested features as agents can easily leverage advanced breakpointing techniques.