Using java debugger causes reproducible memory leak

### Apache NetBeans version

Apache NetBeans 29

### What happened

This is a very old (since NetBeans 8) and easily reproducible memory leak caused by simple debugging of java code. After debugging sessions instances of JPDADebuggerImpl remain registered in memory (owned by Swing related services), each owning large numbers of com.sun.tools.jdi.Packet instances.

### Language / Project Type / NetBeans Component

Java Ant prroject

### How to reproduce

* Open or create a java project (like NetBeans itself)
* Debug the project with the regular/internal debugger of NetBeans
* Stop debugging



* Attach VisualVM, perform a GC and heamp dump
* Look for still visible instances of JPDADebuggerImpl

### Did this work correctly in an earlier version?

No / Don't know

### Operating System

Linux 6.12.74_1 x86_64

### JDK

OpenJDK 64-Bit Server VM (build 21.0.2+13-58, mixed mode, sharing)

### Apache NetBeans packaging

Apache NetBeans binary zip

### Anything else

This issue happens every time the debugger is used and renders NetBeans unusable after some debugging sessions because of low remaining memory. VisualVM-Heapdumps (.hprof) before/after debugging are available on request (100 - 200MB compressed).

### Are you willing to submit a pull request?

No

Reproduce the leak by debugging a Java Ant project, stopping the session, and inspecting a GC heap dump with VisualVM. Start by tracing retained JPDADebuggerImpl instances and their com.sun.tools.jdi.Packet objects through the Swing-related services; done means debugger instances and packets are no longer retained after stopping.

Written by the indexing model from the issue text.