Extend StackFrame to support longer description than name

[hyangah]

Many DAP clients use the values in name when rendering info about a stack frame.

interface StackFrame {
  ...
  /**
   * The name of the stack frame, typically a method name.
   */
  name: string;
  ...
 }

There is no length limit on name, but empirically we found long strings don't work well in some DAP clients (VS Code). See the screenshots included in go-delve/delve#3323 (comment). When the go debug adapter includes both package path (corresponding to "module" in other languages) and the method name in the name, it can produce a very long string.

StackFrameFormat was brought up while we were discussing how to surface both package and method name in the current VS Code UI (microsoft/vscode#193153). According to the conversation in #411, the debug adapter is responsible for formatting and producing the string based on StackFrameFormat. Now where should this potentially long formatted string go?

In the current spec, I cannot find any place other than name, and we are again back to the original problem. Some DAP clients cannot efficiently present a long stack frame name.

What do you think about having an optional longer description field?
I think VS Code can potentially present the longer description in tooltip.
Other DAP clients can also choose to select name and the new longer description based on the need, instead of arbitrarily hiding or truncating name.

[connor4312]

The addition of an optional description?: string field would make sense to me.

    /**
     * Additional, more detailed information about the stackframe.
     */
    description?: string;

[gregg-miskelly]

The expectation of StackFrameFormat is definitely to put the result in name, so I don't think it makes sense for format to instead target a new field. But I could see the utility in a longer name that either doesn't pay attention to StackFrameFormat (probably the best option to me -- keep it simple) or has a new field in StackTraceArguments to control that format.