ActiveReferenceQueue floors processor

### Apache NetBeans version

Apache NetBeans 18 release candidate

### What happened

When building my platform App project, Netbeans floors my processor for no reason at all after a build or two. From what I can tell, a new `ActiveQueue` is started when the `MIMEResolverProcessor` processes the Mime attribute in the source file. This can apparently also happen by the background text analyzer since it does a build too.
I think this is due to the class loaders being different or something? Not sure. I have checked the code and found that `ActiveQueue.activeReferenceQueue` is `null` in one thread, but NOT in the other one. This appears to not be a primary issue as they just wait for things to remove. The issue happens when they do go to do that.
Ah, yes... You see... Once they do that, they get stick an a `while (true)` loop of sorts. When the system detects that this "instance" isn't the original one (I have no idea how that happens BTW since their loaders are different). Somehow, they realize that they aren't the running `ActiveQueue.Daemon` thread and [they throw `InterruptedException`s](https://github.com/apache/netbeans/blob/67c58bfcc0919ca19f27e15c873faaa872d035d4/platform/openide.util.lookup/src/org/openide/util/lookup/implspi/ActiveQueue.java#L64) to [try to exit their loop](https://github.com/apache/netbeans/blob/67c58bfcc0919ca19f27e15c873faaa872d035d4/platform/openide.util.lookup/src/org/openide/util/lookup/implspi/ActiveQueue.java#L73)... which is then caught [right under the thread's `while (true)` statement](https://github.com/apache/netbeans/blob/67c58bfcc0919ca19f27e15c873faaa872d035d4/platform/openide.util.lookup/src/org/openide/util/lookup/implspi/ActiveQueue.java#L140) and ignored. So they just loop, throwing and catching an exception repeatedly.

### How to reproduce

[CpuFloorIssue.zip](https://github.com/apache/netbeans/files/11314246/CpuFloorIssue.zip)
Project attached. Perform a build of it. Do a clean build to trigger it again. My project does it every-time I build, but it is an actual application and therefore bigger.

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

No / Don't know

### Operating System

Mac Mini 2018 with OS 13.2.1

### JDK

OpenJDK 64-Bit Server VM Temurin-19.0.1+10 (build 19.0.1+10, mixed mode, sharing)

### Apache NetBeans packaging

Own source build

### Anything else

A short-term workaround would be to not swallow the exception if the current thread isn't the right one, but I don't think that would just fix the issue.

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

No

Start with platform/openide.util.lookup/src/org/openide/util/lookup/implspi/ActiveQueue.java, especially the referenced lines around the daemon loop and InterruptedException handling. Reproduce the issue by building and clean-building the attached CpuFloorIssue.zip project, then trace how multiple ActiveQueue instances and class loaders reach the loop. Done means the repeated exception loop no longer floors CPU while queue processing remains functional.

Written by the indexing model from the issue text.