Breakpoints for Java lambdas.

[lahodaj]

This is something I was looking at long time ago, but was not very happy about the UI. So I was trying to improve the UI, but I didn't make progress on that, and this got stashed. So, now I decided to try to recover this, even with the not-so-nice UI.

I would consider this patch to be a fairly advanced prototype.

Currently, having code like:

        List.of("a", "b", "c")
            .stream()
            .map(s -> s).filter(s -> !s.isEmpty())
            .forEach(s -> System.err.println(s));
    }

putting a breakpoint at the line with map will mean the debugger will stop at the line when map is called, and then each time any of the lambdas is called. This is rarely what one wants. It would be better to be able to say that I want the debugger to stop at e.g. the first lambda.

This is what this PR is trying to do. There's an ability to specify the breakpoint applies to n-th lambda on the given line. Special values are -1, which means to stop at the line outside of any lambda, and Integer.MIN_VALUE, which means stop each time this line is reached, regardless of any lambdas. This is the way it works on the backend.

Inside the NetBeans UI, it works like this:

• when a line breakpoint is added on a line with lambdas, it is considered to be on the line only, and there's a disable lambda breakpoint added for each lambda automatically. These can then be enabled/disabled independently.
• when the line breakpoint is removed, all the lambda breakpoints are removed as well.

The ability is also used in the DAP Java server, for use in DAP clients (e.g. in VS Code). The UI in VS Code is better, but also has some sharp edges.

Inside NB, it can look like this:

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)