better align setExceptionBreakpoints with the other setXxxException request

[weinand]

There is a desire to treat all breakpoints the same.

Today Exception breakpoints are different because they don't have an ID since there is no way to return the ID from the corresponding SetExceptionBreakpoints request.

One area where this difference between breakpoints hurts a lot, is with error reporting: neither is it possible to return a "failed verification" message from SetExceptionBreakpoints, nor is it possible to send out breakpoint exceptions that contain the error message (because of the lack of an ID).

I propose that we align SetExceptionBreakpoints with the other SetBreakpoints requests and allow to optionally return an array of Breakpoints. These breakpoints can be used to return an ID (so that breakpoint events can be sent), or the error message can be directly returned via the verified and message properties.

[gregg-miskelly]

When fixing this, I would suggest also suggest removing the additional description text added at the end of the following:

debug-adapter-protocol/debugAdapterProtocol.json

Line 1244 in 3fa9748

"description": "The request configures the debuggers response to thrown exceptions.\nIf an exception is configured to break, a 'stopped' event is fired (with reason 'exception').\nClients should only call this request if the capability 'exceptionBreakpointFilters' returns one or more filters.\nIf a filter or filter option is invalid (e.g. due to an invalid 'condition'), the request should fail with an 'ErrorResponse' explaining the problem(s).",

.

[weinand]

It is now possible to return an arrow of Breakpoints from the setExceptionBreakpoints request.
This allows clients to show validation error messages for individual exception breakpoints or filters.

/** Response to 'setExceptionBreakpoints' request.
    The response contains an array of Breakpoint objects with information about each exception breakpoint or filter.
    The Breakpoint objects are in the same order as the elements of the 'filters', 'filterOptions', 'exceptionOptions' arrays
    given as arguments. If both 'filters' and 'filterOptions' are given, the returned array must start with 'filters'
    information first, followed by 'filterOptions' information.
    The mandatory 'verified' property of a Breakpoint object signals whether the exception breakpoint or filter could be
    successfully created and whether the optional condition or hit count expressions are valid. In case of an error the 
    'message' property explains the problem. An optional 'id' property can be used to introduce a unique ID for the
    exception breakpoint or filter so that it can be updated subsequently by sending breakpoint events.
    For backward compatibility both the 'breakpoints' array and the enclosing 'body' are optional. If these elements
    are missing a client will not be able to show problems for individual exception breakpoints or filters.
*/
export interface SetExceptionBreakpointsResponse extends Response {
  body?: {
    /** Information about the exception breakpoints or filters.
        The breakpoints returned are in the same order as the elements of the 'filters', 'filterOptions',
        'exceptionOptions' arrays in the arguments. If both 'filters' and 'filterOptions' are given, the returned array must
        start with 'filters' information first, followed by 'filterOptions' information.
     */
    breakpoints?: Breakpoint[];
  };
}