`vscode-mock-debug` sends `StackFrame#column: 0` response although the debug client sends `columnsStartAt1: true` for initialize

Hi There,

This is more like a question, but I could not get my head around whether vscode-mock-debug violates the DAP constraints or not. Please help to figure out if this sample adapter implementation behaves correctly.

When I start the Debug readme.md launch configuration on the sampleWorkspace as described in the docs, I can see that the debugger will send the following response for the 'stackTrace' request back to the client:

{
    "seq": 0,
    "type": "response",
    "request_seq": 10,
    "command": "stackTrace",
    "success": true,
    "body": {
        "stackFrames": [
            {
                "id": 0,
                "source": {
                    "name": "readme.md",
                    "path": "/Users/a.kitta/dev/git/vscode-mock-debug/sampleWorkspace/readme.md",
                    "sourceReference": 0,
                    "adapterData": "mock-adapter-data"
                },
                "line": 1,
                "column": 0,
                "name": "VS(0)"
            }
        ],
        "totalFrames": 5
    }
}

StackFrame#column from the specs:

Start position of the range covered by the stack frame. It is measured in UTF-16 code units and the client capability columnsStartAt1 determines whether it is 0- or 1-based. If attribute source is missing or doesn't exist, column is 0 and should be ignored by the client.

Since my debug client is initialized with linesStartAt1: true and columnsStartAt1: true, I would expect that the debugger won't send 0 if the source is available.

This is not a problem in VS Code because the range to reveal is adjusted based on the backing ITextModel before dispatching the revealRange API call. 0 will be mapped to 1. So there are no errors if "stopOnEntry": true is in the lunach.json and the debugger starts and stops at the entry point.

But there are other implementations. For example, in Eclipse Theia, the client knows that the debug sessions are initialized with linesStartAt1: true and columnsStartAt1: true and will expect 1-based line and column values as defined in the specs. Theia will map the position of the StackFrame to an LSP (0-based) position, then when revealing the range in the monaco editor, Theia will convert the 0-based LSP position to a 1-based monaco position. Unfortunately, it does not work reliably as the vscode-mock-debug unexpectedly sends column: 0 although columnsStartAt1: true.

One can argue that it's the client's responsibility to map the Position of the stack frame to the appropriate one, and I have tried to "repair" the position based on the ITextModel, but it does not work. For example, a { line: 0, character: -1 } is not a valid Position in the LSP word, as the properties must be unsigned integers.

Question:
Is the vscode-mock-debugger DAP compliant when it's using the default col: number = 0 0 value for the column when creating the StackFrame instance here:
https://github.com/microsoft/vscode-mock-debug/blob/95d0052629b1cc65a0647f927cc1b13f4407b7c8/src/mockDebug.ts#L386

Thank you!

Start with src/mockDebug.ts at the StackFrame construction around line 386, then read the DAP StackFrame and initialize specifications. Reproduce the stackTrace response using the sampleWorkspace and inspect the referenced vscode-debugadapter default column behavior. Done means documenting or correcting the adapter's compliance and verifying the resulting position with a focused test or reproduction.