call setExceptionBreakpoints only if more than one filter is specified in the corresponding capability

[weinand]

[isidorn]

@weinand I propose to do this in march so we do not break any adapters that are not yet supporting exceptionBreakpoint capability?

[weinand]

@isidorn sure, this was not meant to be for this sprint.

[isidorn]

Please note that I no longer manually set 'all', 'uncaught' in case the adapter is not sending exception breakpoints as part of capabalities.
Due to this all adapters should send a list of exception breakpoints that they support as part of capabilities returned by the initialise call.
Debug Protocol Capabilites
Example how node debug does it

@daviwil @roblourens @lukehoban @gregg-miskelly @felixfbecker

[daviwil]

cc @rkeithhill

[rkeithhill]

We support returning Capabilities from the initialize request now in the PowerShell extension. We do not return the exceptionBreakpointFilters field. I believe this should be effectively declaring that we do not support exception filters but we still get the setExceptionBreakpoints request and the breakpoint UI shows the exception breakpoints (all and uncaught). Sounds like this change, would eliminate those messages. Does it fix the UI as well?

BTW WRT to the debug protocol, is it better (more efficient) to not return a field at all versus returning null?

[gregg-miskelly]

@isidorn I think I know the answer, but just to confirm -- this is for March, correct?