Fix breakpoint verification UI for the multi session case

[weinand]

Problem:
If two (or more) concurrent debug sessions return differing verification status for a (shared) breakpoint, then the outcome in the UI is not clear, e.g. we show the verification error for the breakpoint but he breakpoint actually verified fine in one of the sessions. This should not affect the ability to hit a verified breakpoint and miss an unverified breakpoint.

3 Possible solutions:

• The UI shows multiple breakpoint stati with a new UI: if a BP has different stati, we do not show the red dot but something else (and a hover could show the individual stati per debug session).
• Since VS Code has the concept of an active debug session, the UI could multiplex the different breakpoint stati: the UI reflects only the status of the active debug session.
• we use voting, e.g. we show the breakpoint verified if it got verified in at least one session.

Today VS Code uses approach 3 but we should strive for solution 2.

In addition we should clarify/improve the DAP in order to support a "don't care" verification status.

[isidorn]

I have refactored the breakpoint model such that now there are core breakpoint attributes which are edited by user explicitly and attributes on top which belong to a debug adapter session.
So now we use the second solution in your proposel above. And it can happen that breakpoints change properties once a user switches the active debug session (for example a breakpoint can appear as verified in one session and unverified in the other, but the line number and other things can changes as well)

Since I have reafactored a big part of the model we should keep our eyes open for regressions

fixed via 57d7e6f and cf10e47

fyi @roblourens